CircleCI Logo
Navigation Menu Icon

Migrate from deploy to run

Language Icon 5 months ago · 4 min read
Cloud Server v4+
Contribute Go to Code

Introduction

A configuration file that uses the deprecated deploy step must be converted, and all instances of the deploy step must be removed, regardless of whether or not parallelism is used in the job.

  • Does your job have parallelism of 1? Swap out the deploy key for the run key. Nothing more is needed to migrate.

  • Does your job have parallelism > 1? There is no direct replacement for the deploy step if you are using parallelism > 1 in your job. The recommendation is to create two separate jobs within one workflow - a test job, and a deploy job. The test job will run the tests in parallel, and the deploy job will depend on the test job. The test job has parallelism > 1, and the deploy job will have the command from the previous deploy step replaced with run and no parallelism. See examples in this guide.

Parallelism > 1

The following is an example of replacing the deprecated deploy step in a configuration file that has parallelism > 1.

The code in the first example below is deprecated. Do not copy. 
# Example of deprecated syntax, do not copy
version: 2.1
jobs:
  deploy-step-job:
    docker:
      - image: cimg/base:stable
    parallelism: 3
    steps:
      - checkout
      - run:
          name: "Say hello"
          command: "echo Hello, World!"
      - run:
          name: "Write random data"
          command: openssl rand -hex 4 > rand_${CIRCLE_NODE_INDEX}.txt
      - run:
          name: "Emulate doing things"
          command: |
            if [[ "$CIRCLE_NODE_INDEX" != "0" ]]; then
              sleep 30
            fi
      - deploy: #deprecated deploy step, do not copy
          command: |
            echo "this is a deploy step which needs data from the rand"
            cat rand_*.txt

workflows:
  deploy-step-workflow:
    jobs:
      - deploy-step-job

If you are entirely reliant on external resources (for example, Docker containers pushed to a registry), you can extract the deploy step above as a job, which requires doing-things-job to complete. doing-things-job uses parallelism of 3, while deploy-step-job performs the actual deployment. See example below.

version: 2.1
jobs:
  doing-things-job:
    docker:
      - image: cimg/base:stable
    parallelism: 3
    steps:
      - checkout
      - run:
          name: "Say hello"
          command: "echo Hello, World!"
      - run:
          name: "Write random data"
          command: openssl rand -hex 4 > rand_${CIRCLE_NODE_INDEX}.txt
      - run:
          name: "Emulate doing things"
          command: |
            if [[ "$CIRCLE_NODE_INDEX" != "0" ]]; then
              sleep 30
            fi
  # create a new job with the deploy step in it
  deploy-job:
    docker:
      - image: cimg/base:stable
    steps:
      - run: # change "deploy" to "run"
          command: |
            echo "this is a deploy step"

workflows:
  deploy-step-workflow:
    jobs:
      - doing-things-job
      # add your new job and make it depend on the
      # "doing-things-job"
      - deploy-job:
          requires:
            - doing-things-job

Using workspaces

If files are needed from doing-things-job in the deploy-job, use workspaces. This enables sharing of files between two jobs so that the deploy-job can access them. See example below.

version: 2.1
jobs:
  doing-things-job:
    docker:
      - image: cimg/base:stable
    parallelism: 3
    steps:
      - checkout
      - run:
          name: "Say hello"
          command: "echo Hello, World!"
      - run:
          name: "Write random data"
          command: openssl rand -hex 4 > rand_${CIRCLE_NODE_INDEX}.txt
      - run:
          name: "Emulate doing things"
          command: |
            if [[ "$CIRCLE_NODE_INDEX" != "0" ]]; then
              sleep 30
            fi
      # save the files your deploy step needs
      - persist_to_workspace:
          root: .     # relative path to our working directory
          paths:      # file globs which will be persisted to the workspace
           - rand_*

  deploy-job:
    docker:
      - image: cimg/base:stable
    steps:
      # attach the files you persisted in the doing-things-job
      - attach_workspace:
          at: . # relative path to our working directory
      - run:
          command: |
            echo "this is a deploy step"

workflows:
  deploy-step-workflow:
    jobs:
      - doing-things-job
      - deploy-job:
          requires:
            - doing-things-job

The example above is effectively using a "fan-in" workflow which is described in detail on the workflows page.

Support for the deprecated deploy step will eventually be removed. Ample time will be given for customers to migrate their configuration.