Each commit to the remote github repository will trigger the CI pipeline which is handled by circleCI. Each microservice comes with it's own set of unit/component tests. So we will like to know if the build is passing at every point in time and the current test coverage. Before a PR is merged, the build must be running and the test coverage must be high(over 90%). The CI pipeline via circleCI is already up and running.
The CD pipeline will be built using concourse-ci. ConcourseCI will be installed on a VM running on google cloud(1CPU, 3.75GB RAM, 50GB Storage, ssh_keys: CONCOURSECI_SSH_KEYS). Once a PR is merged into develop, the CD pipeline kicks off by pulling develop branch of all microservices and running their unit tests. We currently have about 5 microservices, 1 api-gateway and 1 acceptance test repo:
| Repo Name | DEPLOY KEY | DOCKER BASE IMAGE | TEST COMMAND |
|---|---|---|---|
| micro-api-gateway | API_GATEWAY_KEY | golang:1.6.2 | ./coverage.sh |
| micro-authentication-service | AUTHENTICATION_KEY | golang:1.6.2 | ./coverage.sh |
| micro-authorization-service | AUTHORIZATION_KEY | node:argon | gulp test |
| micro-fellowship-role-service | FELLOWSHIP_ROLE_KEYS | node:argon | npm test |
| micro-user-management-service | USER_MGT_KEYS | node:argon | npm test |
| micro-acceptance-tests | ACCEPTANCE_KEY | golang:1.6.2 | godog |
| micro-assessment-service | ASSESSMENT_KEY | node:argon | npm test |
Once the unit tests passes, a docker image will be built from each repo with a specific tag ending in .dev. These images will be pushed to google container registry. The url of each image will be in this form -> us.gcr.io/microservices-kube/image-name:image-tag. Access to google cloud platform will be provided via GOOGLE_CLOUD_AUTH_KEY. Once the containers are in google container registry, they will all be deployed to test environment(alternatively, a test cluster will be spinned up and the containers will be deployed to the newly created cluster).
We could run smoke test after the deployment to test environment has completed to accertain that all our services were deployed correctly. This is followed by running acceptance test. Our acceptance test reside in a repo which will be pulled at this point. The test will make calls to the api-gateway of the test environment and verify the response received. If all the acceptance tests passes, we can say at this point that our code is ready to be deployed to production.
In the deployment to production phase, we start with building another docker image without the .dev at the end of the tag name. After building the image, the image will also be pushed to google container registry. At the same time, we issue a merge request to the github repo that initiated the pipeline. This request will merge the current state of develop into master.
At this point, we are in the final stage of the pipeline and this will require human intervention. This is the stage where we finally deploy to production. In the future, this stage can also be automated.
NOTE: I will be sending out all the variables defined in this doc via lastpass.