This is the artifactrepository where your compiled binaries, scripts, and executables can be stored for later consumption. This replaces the need for package managers, which teams generally manage on their own, although they sometimes opt for a remote-hosted offering. Out-of-the-box compatibility with PyPI, Maven, NPM, and so on makes it easy to store your artifacts directly in AWS.
We have just scratched the surface by discussing these services that enable CI. There is more to them, which will be covered in the following chapters.
Next, let’s discuss delivery and deployment methodologies, which prepare or deploy builds for production usage.
CD and continuous deployment
Successful implementations of CI practices allow for the automatic preparation of code release activities. High-performing teams typically automate an integration test suite while practicing CD and continuous deployment. They deploy the code in production-like environments, measure performance, load tests, and evaluate known edge cases before deploying in live environments.
The only difference between CD and continuous deployment is that the former does not automatically promote the artifact to production, and there is no need for rollbacks when failures are detected. Continuous delivery prepares a production-ready build, but the final deployment still requires human intervention. With the increasing maturity of tooling and automation, the teams at some stage start automatically rolling out code to production environments, which is continuous deployment. AWS offers two main services in these areas.
AWS CodeDeploy
As the name suggests, this is a code deployment service. It provides support for a variety of compute offerings, such as EC2, AWS container services, and even on-premises machines. Furthermore, several deployment strategies control the rollout process for you and back it up with health checks that add to the visibility and reliability of code rollout procedures.
Depending on the application architecture and rollout methodology, one of the following could be used:
- In-place deployments: Update code in all instances in the application group followed by a service restart. The scope of change could be controlled by going all in at once or doing a controlled release.
- Blue-green deployments: An identical environment is set up and CodeDeploy deploys different versions in both, giving the end user the capability to switch the production traffic when possible and revert when issues are observed.
- Canary deployments: This is a deployment strategy in which new code is released in phases. For example, every few minutes, X% of the servers get the code upgrade, and this continues until a rollback is explicitly performed.