KB Blog
Navigation

Workflow and deployment

To deploy an application or a website, an additional step can be appended to do the job. However, it is better to separate build job from deploy job.

Workflow

Build and Deploy steps work the best when coupled within a workflow. A basic workflow is:

workflows:
  version: 2
  jobs:
    - build
    - deploy

Filtering

Jobs can be filtered and conditionally be executed or ignored:

  • Branch name
  • Tags

Filtering can be:

  • inclusive (only:)
  • exclusive (ignore:)
  • using Regex. E.g. to filter on feature/* branches only: 
    filters:
  branches:
    only: /^feature\/.*/

Filtering are forwarded to “children” jobs. For example:

workflow:
  version: 2
  build-deploy:
    jobs:
      - build
      - test
      - approval:
          requires:
            - test
          type: approval
      - deploy-dev:
          requires:
            - test
          filters:
            only:
              - develop
      - deploy-prod:
          requires:
            - approval
  • Commits on develop branch triggers: build > test > deploy-dev
  • Commits on master branch triggers: build > test > approval > deploy-prod

Scheduling

Example:

workflow:
  version: 2

  nightly:
    triggers:
      - schedule:
          # Time is UTC: deploy every day at 00:00 UTC
          cron: "0 0 * * *"
          filters:
            branches:
              only:
                - develop
    jobs:
      - build
      - deploy

Manual approval

workflows:
  version: 2

  build-deploy:
    jobs:
      - build
      # Approval job name is arbitrary
      - approval: # <<< A job that will require manual approval in the CircleCI web application.
          type: approval # <<< This key-value pair will set your workflow to a status of "On Hold"
          requires:
            - before_approval
      - deploy-prod:
          requires:
            - approval

Persisting artifacts

Folder may be persisted from a job to another one to avoid recompiling. Use persist_to_workspace to save and attach_to_workspace to load:

jobs:
  build:
    working_directory: ~/repo
    steps:
      - persist_to_workspace:
          # Must be an absolute path, or relative path from working_directory.
          # This is a directory on the container which is  taken to be the root
          # directory of the workspace.
          root: ./
          # paths are relative to root and MUST be defined
          paths:
            - folder/path1/
            - folder/path2/
  deploy:
    # Warning! not the same as "build"
    working_directory: ~/
    steps:
    steps:
      - attach_workspace:
          # Must be absolute path or relative path from working_directory
          # => load `root` of persisted to workspace
          at: ~/repo

To make the workspace available through jobs, it has to be shared via a workflow where the jobs dependencies defines who can access what:

workflows:
  version: 2
  jobs:
    - build
    - deploy:
        - requires:
            # as "build" must run before "deploy", the workspace after "build"
            # is available for attaching
            - build

Warning: .circleci folder cannot be copied!

Sources:

circleci workflow deploy