|
| 1 | +# CircleCI Pipeline Template |
| 2 | + |
| 3 | +## Configuration |
| 4 | + |
| 5 | +### Requirements |
| 6 | + |
| 7 | +Requires you to configure the below [CircleCI Environment Variables](https://circleci.com/docs/2.0/env-vars/): |
| 8 | + |
| 9 | +- AWS_DEFAULT_REGION # Region of your cluster |
| 10 | +- AWS_ECR_ACCOUNT_URL # {awsAccountNum}.dkr.ecr.{region}.amazonaws.com |
| 11 | + |
| 12 | +Required if you have one aws account per environment: |
| 13 | +- AWS_ECR_REPO_ACCOUNT_ID # AWS account id of the account that contains the ECR repo to use |
| 14 | +- AWS_CLUSTER_AUTH_ROLE_ARN_STAGING # ARN of the role for the circleci user to assume in staging |
| 15 | +- AWS_CLUSTER_AUTH_ROLE_ARN_PRODUCTION # ARN of the role for the circleci user to assume in production |
| 16 | + |
| 17 | +### Parameters |
| 18 | + |
| 19 | +#### language |
| 20 | + |
| 21 | +Options: |
| 22 | + |
| 23 | +- go |
| 24 | +- nodejs |
| 25 | + |
| 26 | +Note: Don't see your language here? Add a pull request. Templates are written using the [Go Templating Language](https://golang.org/pkg/text/template/). |
| 27 | + |
| 28 | +##### assumeRole |
| 29 | + |
| 30 | +Boolean to use the AWS assume role or not. Role you assume is based on clusterAuthenitcationRoleArn. |
| 31 | +You'll need to provide the env vars above if this is true. |
| 32 | + |
| 33 | +##### circleCIPro |
| 34 | + |
| 35 | +If you've got a Performance account with CircleCI enable this for faster docker builds. |
| 36 | + |
| 37 | +##### stagingClusterName |
| 38 | + |
| 39 | +The name of the staging EKS cluster. |
| 40 | + |
| 41 | +##### productionClusterName |
| 42 | + |
| 43 | +The name of the production EKS cluster. |
| 44 | + |
| 45 | + |
| 46 | +### Example |
| 47 | + |
| 48 | +See our [example config](commit0.example.yml) for usage. |
| 49 | + |
| 50 | +## Deployment Process |
| 51 | + |
| 52 | +### Branch Deploys |
| 53 | + |
| 54 | +1. [Checkout](#checkout) |
| 55 | +2. [Unit Tests](#unit-tests) |
| 56 | + |
| 57 | +### Master Deploys |
| 58 | + |
| 59 | +1. [Checkout](#checkout) |
| 60 | +2. [Unit Tests](unit-tests) |
| 61 | +3. [Build and Push Image](#build-and-push-image) |
| 62 | +4. [Deploy Staging](#deploy-staging) |
| 63 | +5. [Integration Tests](#integration-test) |
| 64 | +6. [Deploy Production](#deploy-production) |
| 65 | + |
| 66 | +## Checkout |
| 67 | + |
| 68 | +We checkout code in a separate step and then save to a shared workspace throughout the rest of the build. This is done to avoid needing to run the checkout in multiple steps throughout the build. |
| 69 | + |
| 70 | +## Unit Tests |
| 71 | + |
| 72 | +We run the tests inside a Go container. This runs parallel to the build process to save time. We run unit tests on branches before merging to master so these should never fail on the master branch. Results are piped into go-junit-reporter to allow CircleCI to parse them for [Insights](https://circleci.com/build-insights/gh/Vin65/shipping-service/master). |
| 73 | + |
| 74 | +## Build and Push Image |
| 75 | + |
| 76 | +Uses the ECR orb (See: [Orbs](#orbs)) to build the Dockerfile and push the image up to ECR. |
| 77 | + |
| 78 | +## Deploy Staging |
| 79 | + |
| 80 | +Still finishing up with this, currently it just runs the command `make deploy-staging` |
| 81 | + |
| 82 | +## Integration Tests |
| 83 | + |
| 84 | +Set of tests that need to run against a working version of the application. These are run after deploying to a staging or testing server. |
| 85 | + |
| 86 | +## Deploy Production |
| 87 | + |
| 88 | +This does the same EKS deployment, just waits for other builds to finish deploying first. |
| 89 | + |
| 90 | +## Orbs |
| 91 | + |
| 92 | +### AWS |
| 93 | + |
| 94 | +- [ECR Orb](https://circleci.com/orbs/registry/orb/circleci/aws-ecr) |
| 95 | +- [EKS Orb](https://circleci.com/orbs/registry/orb/circleci/aws-eks) |
| 96 | +- [CLI Orb](https://circleci.com/orbs/registry/orb/circleci/aws-cli) |
| 97 | + |
| 98 | +We use multiple AWS orbs to simplify the deployment process. Firstly to build the image and push to the repo, we use the `aws-ecr` orb. This just combines the commands needed to build a docker image, tag it, and push to ECR. The tags are dealt with by the `version-tag` orb (see below). |
| 99 | + |
| 100 | +### Slack |
| 101 | + |
| 102 | +- [Slack Orb](https://circleci.com/orbs/registry/orb/circleci/slack) |
| 103 | + |
| 104 | +You'll need to set up a slack webhook to post messages to a channel in Slack. You can do it in the [Incoming Webhooks](https://winedirectteam.slack.com/apps/A0F7XDUAZ-incoming-webhooks?next_id=0) page. This is then added as an environment variable on your project with the name `SLACK_WEBHOOK` as per the [Slack Orb Documentation](https://circleci.com/orbs/registry/orb/circleci/slack). |
| 105 | + |
| 106 | +### Commit Version Tag |
| 107 | + |
| 108 | +- [Version Tag Orb](https://circleci.com/orbs/registry/orb/commitdev/version-tag) |
| 109 | + |
| 110 | +This is a custom orb used by (Commit)[https://commit.dev] to create a tag for docker images that is easier to work with. Instead of using the full Git SHA |
| 111 | +as the docker image tag, we use the build number from CircleCI and a short version of the Git SHA (first seven characters only). You'll find the tag for each build in the "Create Version Tag" step inside the `build_and_push` job. |
| 112 | + |
| 113 | +E.g. `Created version tag: VERSION_TAG=164-27a3d39` |
| 114 | + |
| 115 | +This is done to increase the readability, make the numbers sortable and still guarantee uniqueness with a high degree of certainty. |
| 116 | + |
| 117 | +### Queue |
| 118 | + |
| 119 | +- [EddieWebb Queue Orb](https://circleci.com/orbs/registry/orb/eddiewebb/queue) |
| 120 | + |
| 121 | +This orb is used to prevent multiple deployments going out at the same time. By using the CIRCLECI_API_KEY to access the current running builds, it's able to check that the current build is the oldest in the queue, and therefore is able to run first. Other builds in the queue will be put into a wait/retry loop until all builds before them have finished. |
| 122 | + |
| 123 | +This is run before the deploy production step to prevent two builds deploying to production at the same time. |
| 124 | + |
| 125 | +```yaml |
| 126 | + - queue/block_workflow: |
| 127 | + time: '30' # hold for 30 mins then abort |
| 128 | + requires: |
| 129 | + - wait_for_approval |
| 130 | +``` |
0 commit comments