My CI/CD on AWS

garvit singh
2 min readJan 7, 2019

--

Everyone likes CI/CD, right! AWS being norm today, let’s shed some light on the best practices.

Everything being talked here is in context of AWS services, AWS CodeCommit for source control and AWS CodePipeline with AWS CodeBuild for CI/CD.

1. Continuous Integration

We use CodeCommit with CodePipeline to facilitate continuous integration. With source control there are certain things you should be doing with each commit; running eslint and prettier for enforcing standards and formatting, running unit tests to validate the changes, and scanning for known vulnerabilities. This can be made a part of your git pre-commit hook very easily.

(please note example taken from node project. It implies running eslint, npm test, prettier and npm audit in the given order.)

sample package.json
sample git pre-commit hook

2. Continuous Delivery

Once your code has been committed to source control, you would ideally want your CI/CD pipeline to get triggered off that. CodePipeline integrates very nicely with CodeCommit and other services to streamline the whole process.

In the below example, you could see in addition to CodeCommit being source control, we have a scan and a build stage.

Scan Stage: Here we use CodeBuild to run a scanning tool to identify any security vulnerabilities like secret/access keys etc. You may want to run any tool that you or your company leverages but it is always a good idea to scan the source for potential security loop holes before we stage the artifacts publicly.

Build Stage: Here again we use CodeBuild to run our unit tests and build the application binary, which would eventually be staged or deployed.

Deploy Stage: (not in image) There are several ways to go about deployment. You can either invoke a Lambda function, deploy it on CodeDeploy or simply stage the assets on Amazon S3 bucket. In our case we stage the application assets on S3.

AWS CodePipeline

Conclusion

There are several flavors to CI/CD. It is important to keep it simple for developers so it doesn’t impact the velocity of delivery and at the same time keep it highly efficient. We have been using this mechanism in our team internally for little less than a year now, having delivered about 100 applications. It has been very helpful for our developers, hope you find the recommendations useful in your CI/CD process too.

--

--