Companies that want to increase their ability to deploy faster and increase uptime are using Landing Zones in AWS with Continuous Integration and Continuous Delivery (CI/CD). With benefits for security, operations, development and the business, CI/CD helps developers deliver code more frequently and more reliably with the help of DevOps automation. In today’s article, we’ll take a look at the benefits of pairing a Landing Zone with CI/CD. Spoiler alert: together they multiply the business’s ability to grow efficiency, productivity, security and time to market.
Landing Zones play an important role in any organization’s transition from a traditional on-premises Development - IT Operations framework to a cloud-based DevOps model as they provide much-needed efficiency, standardization, and governance. A safe place for services to land as they move through delivery pipelines, landing zones are part of a proven framework for delivering services with greater quality and speed.
The landing zone catches service components as they are delivered via processes. These processes, (which we outline below) are all part of CI/CD best practices designed specifically to automate the delivery of services. Clearly, Landing Zones and CI/CD go hand-in-hand.
Flux7 Landing Zones are a cloud implementation service that provides enterprise customers with a rapid route to securing cloud services. Download our Getting Started Guide today:
The Landing Zone-CI/CD Marriage
Much like the old adage, “easier said than done,” deploying infrastructure, application patterns and application code on top of a landing zone with multiple types of files and technologies can be difficult, despite its apparent simplicity. As a result, at Flux7, we have included a model CI/CD in our Gold Landing Zone offering, which follows the process here. While CI/CD projects can be complicated, our goal is to remove the complexity and help enterprises focus on customizing the CI/CD to meet their specific technical, process and business needs. Let’s walk through the process:
- CodeCommit - The journey begins with AWS CodeCommit where the code is stored. Developers check code into a master or dev branch that is shared and typically mapped to the lowest environment (most frequently Dev rather than test or prod). Note that while we use AWS CodeCommit in this example, we frequently see customers using Git, or other distributed, multi-branch repositories.
- Continuous Integration (CI) - Is the build stage. This stage includes automated unit testing, feature testing, dependencies, libraries and other components that are added and part of the compilation process (e.g. Java’s output would be a JAR file). The idea here is to let the machine do the build, including integrating all the parts and components.
When it comes to infrastructure as code (IaC), we are focused less on building infrastructure per se, but rather on pushing code, templates, and modules to deliver when infrastructure provisioning is requested. CI, as it relates to IaC, is focused more on checking code into different branches and features.
Another important part of CI is metrics, such as the amount of time a build takes. With data in hand, teams can effectively ask how and where to improve their efforts, e.g. ‘if we were to use Docker, could we speed our build time?’ While CI knowledge among development teams is high, we find that many projects stop at continuous integration and delivery, deploying to the lowest environment, but without much (if any) unit, feature, integration, and/or smoke testing. The more mature the team, the faster they are able to iterate (that is, commit code to the repo); more mature teams also have more robust feature test levels that result in fewer breaks or other issues.
- Continuous Delivery (CD) - Directly following CI, the CD phase is key to improving speed to market. While we won’t go into semantics here about the differences between continuous delivery and continuous deployment, for the sake of today’s article, we will view CD as having full confidence to deploy into production. One of the reasons CD gives this confidence is because it automatically creates testing environments, with infrastructure and applications that can be exactly the same as production. With the knowledge that code is tested in environments that resemble production, dev can be sure that the result of CD is code changes, releases, and/or updates that can be put into production. While we see many teams delivering CI in one form or another, CD presents a real opportunity for organizations to separate themselves as high performers.
- Golden AMI - Included in the above processes, the Golden AMI is a security-approved image for a specific OS. Created with the security team’s input and approval, the Golden AMI ensures that developers are following the organization’s AWS account security best practices.
- Application AMI - Is based on the Golden AMI with application development best practices added -- for a specific environment, for example -- to effectively deploy security guidance into production. Unlike the Golden AMI, the Application AMI shall be owned and managed by the Application team.
CI/CD is a workflow process and the more mature your approach to it, the more automation you will be able to build in for testing, integration, security, scanning, and more. Moreover, as you mature, the more you can calibrate your processes to suit your specific business needs.
Importantly, CI/CD is a win-win for everybody. Security teams benefit as the only code that moves into production passes security policies, without the intervention of the security team. Development benefits as they are able to deploy tested, approved code faster to production. Operations benefits as the only code permitted into production has run through all of these tests, which means significantly less downtime, fewer rollbacks, and less manual intervention. And, the business benefits from automation that speeds the ability to innovate, improves security, improves operations, and decreases costs.
CI/CD Automation in Action
Using the above guidelines, let’s walk through a generic CI/CD process using the graphic below as our guide. Starting with our code repository, AWS CodeCommit, where we have stored all our code for infrastructure, applications, and application configuration. Once code is committed, Jenkins is activated. Jenkins calls Packer which in turn builds a Golden AMI, ensuring security is built in from the start.
Once the Golden AMI is baked, we launch it. In this example, we are creating an Application AMI with NGINX and New Relic, so using Ansible we install agents for these two applications. Once baked together, we are able to use the Application AMI on other resources.
In our example, once the Application AMI is baked, Jenkins uses CloudFormation to deploy IaC, building out subnets, an autoscaling group, and a load balancer. While your environment is undoubtedly more complex than our example, the beauty of an automated CI/CD process will shine that much more, as when all the configuration is pre-done and ready to deploy, you’ll find it that much more easy to deploy and delete once you're done with it. Moreover, for compliance in cloud computing, this immutable, defined in code process demonstrates the power of traceability, helping affirm your system state at a given point in time.
Avoiding Technical Debt
CI/CD paired with a Landing Zone can deliver via automation the ability to deliver code faster with consistency and security. By building infrastructure correctly from the start, organizations are able to avoid lifting and shifting technical debt to the cloud, resulting in fewer firefights and incidents moving forward. Last, with automation teams are able to ensure that technical assets are configured appropriately every time, reducing technical debt moving forward.
Interested to learn more about how CI/CD, landing zones and serverless can benefit your business? Join AWS and Flux7 as they present a series of one day workshop this June across the Great Lakes region. Get additional information and register here.