CircleCI Pipeline Integration¶

Open the .circleci/config.yaml
At the top of your config.yaml where the Orb section is defined, add the following Orb (if it’s already there, just make sure it is set to use the most recent version:

deployment: client/productcore-deployment-orb@0 update link

In the variables section of your config.yaml (usually at the top), change the chart-path variable to be ./deployment/helm

For each of your deployment workflows (Dev, QA, Prod), do the following:

a) Find the job that deploys your application through Jinja. Remove this job from the workflow either by deleting it or commenting it out.

Example Job:

    - app-release/deploy:
        name: Deploy App to Dev Environment
        appname: *appname
        team-name: *team
        aws-region: *nonprod-aws-region
        <<: *circle-ci-service-account
        cluster-name: di-nonprod-cluster
        <<: *circle-ci-context
        environment: dev
        extra-deploy-options: ordersUrl=http://order-search-api.order-dev.svc.cluster.local/v1/orders orderStatusUrl=https://hylt2.client.client.com/myaccount/orderStatus productsUrl=https://hylt2.client.client.com/product/info clientUserDataURL=https://hylt2.client.client.com/analytics/userdata?pageType=content #[update link](liatrio-tag)
        before-deploy:
            - apply-authz-filter:
                appname: *appname
                env: dev
            - apply-shell-filter:
                appname: *appname
                core_namespace: productcore-dev
        requires:
            - Build and Publish Application Image
            - Run Image Security Scan

b) Where the Jinja deployment job was, replace it with the following:

    - deployment/bluegreen-deploy:
        name: Deploy App to [environment] Environment
        chart-path: *chart-path
        <<: *circle-ci-context
        <<: *circle-ci-service-account
        namespace: [team_name]-[environment]
        release-name: *appname
        values-blue-file-path: ./deployment/helm/values-dev-blue.yaml
        values-green-file-path: ./deployment/helm/values-dev-green.yaml
        image-tag: $CIRCLE_SHA1
        team-name: *team
        environment: [environment]
        helm-timeout: 10m
        cluster-name: [cluster_name]
        aws-region: [aws_region]
        use-reset-value: no
        requires:
            - Build and Publish Application Image
            - Run Image Security Scan
    - deployment/bluegreen-switch-environment:
        name: Switch env
        <<: *circle-ci-context
        <<: *circle-ci-service-account
        chart-path: *chart-path
        release-name: *appname
        namespace: [team_name]-[environment]
        team-name: *team
        environment: [environment]
        cluster-name: [cluster_name]
        aws-region: [aws_region]
        requires:
            - Deploy App to [environment] Environment
    - deployment/bluegreen-remove:
        name: Remove inactive environment
        chart-path: *chart-path
        <<: *circle-ci-context
        <<: *circle-ci-service-account
        release-name: *appname
        namespace: [team_name]-[environment]
        team-name: *team
        environment: [environment]
        cluster-name: [cluster_name]
        aws-region: [aws_region]
        requires:
            - Switch env

c) You will need to replace anything in [] (including the []) in the above snippet:

[aws_region] = use what was defined in the Jinja job you are replacing
[cluster_name] = use what was defined in the Jinja job you are replacing
[team_name] = your teams name
[environment] = the environment (dev, qa, prod) that this job is being added to

The above workflow does not add any manual approval steps and does not include any testing to occur before the switch from blue->green or green->blue. If you would like to wait to do the swap until manual intervention or testing has occurred, you will need to add in manual approval steps.

Your First Deployment with Helm (Per environment)¶

The first time you deploy to an environment with Helm, you will need to break the ownership that Jinja has on your Kubernetes resources. To do this, you will need to do the following against the environment you are deploying to: 1. Change your local Kubernetes context to the environment you are deploying through Helm to: kubectl config use-context [context name] 2. Use the following command to get k9s running remotely in that context aws exec [profile] -- k9s -n [namespace] 3. Delete all of the kinds that were previously installed via Jinja [pods,svc,deploy,hpa,gw,vs,pdb,rs,secret, ingresssecrete, destinationrule, serviceentery]

When you are ready to go to prod, you will need to access the prod cluster after running this command: dpctl break-glass

Second Deployment with Helm and beyond¶

After your first deployment in each environment has completed successfully, there are no additional steps you need to take going forward unless you make changes to the files inside of the ./deployment/helm folder.

If you need to make changes to these files, you will need to update your .circleci/config.yaml to get those changes to take effect.

To do this find the location of use-reset-value: no in your deployment job and change it’s value to yes. If you do not see this in your bluegreen-deploy job, then you will need to add it there.

This will tell the Orb to take your changes. After you have successfully deployed your changes, you should reset the value back to no

Testing your deployment before switching¶

If you want to test your deployment before allowing it to switch from blue->green or green->blue, you can do so by adding job(s) before the deployment/bluegreen-switch-environment job. This can be automated test jobs or a manual approval job.

To access the “offline” color environment, you will need to add the following custom header to the HTTP requests that you execute or your automated tests execute:

Header Name: x-env
Header Value: test

Rolling Back to Jinja¶

If for some reason you encounter an issue and need to rollback to Jinja, you can do so by reverting the PR you did to merge this into your main/master branch. You may need to run the following command in each environment to allow Jinja to deploy again: dpctl break-glass