AWS CodePipeline, CloudFormation & Continuous Delivery
- November 28, 2016
Continuous Delivery (CD) is a core facet of successful DevOps and as a result, a core Flux7 strategy for implementing DevOps-based IT modernization. At Flux7, we always view DevOps as streamlining the delivery of not just Code but also the delivery of Infrastructure (networking, firewalls, VMs), Server Configuration (software packages such as Apache or JAVA), and Security Rules (policies for AWS Config Rules or HashiCorp Vault). Among these, efficient delivery of infrastructure and configuration are both very critical for full-stack agility. For our customers in AWS, our typical choice for infrastructure delivery is CloudFormation. We like AWS CloudFormation because it is native to AWS, follows a simple YAML or JSON syntax, and has deep integration with other AWS Services such as the AWS Service Catalog.
Continuous delivery of infrastructure with CloudFormation implies the following workflow: The CloudFormation templates are saved in a version control system. If a user wishes to create a change to the infrastructure, they clone the current template, make a change, review the change, and push the template back to the code repository. The CI/CD tool detects the new change, and triggers an update of the CloudFormation stack with the new change. Historically, the tool that we have used for implementing CD with CloudFormation is Jenkins. While the solution with Jenkins works well, we were keen to hear that AWS has announced an update to CodePipeline, with the ability to now build CD workflows for CloudFormation Stacks. We can now implement CD of infrastructure using a hosted service instead of maintaining our own Jenkins instance in AWS.
As heavy AWS CloudFormation users, we couldn’t wait to dive in and look in more detail at AWS’s news on how the new CodePipeline update would work with CloudFormation.
What does this mean? Together, the two technologies allow us to automatically build and test changes to AWS CloudFormation templates before they are promoted to production. While automation is core to building continuous delivery, it’s important that this update allows us to automatically build, test, and deploy code every time there is a code change, as based on our defined release process. However, most release processes also include manual approval steps — say before promoting to the production environment. So, the new update also easily facilitates these manual steps, keeping track of where we are at in the process and automatically moving on to the next step once the manual step is finished.
Two things that we really like about the new CodePipeline update are that it allows us to make further use of Infrastructure as Code and it allows us to rapidly and reliably make changes to our client’s AWS infrastructure, furthering the benefits of CD. Combined, these two are powerful. Let’s explore:
Ideally, CodePipeline delivery operates like brakes on a race car, giving you the control you need in order to go faster. However, for code to move through the pipeline at speed, the supporting infrastructure needs to be created and configured at a similar pace. After all, what good would speedy code delivery be if you had to wait days or weeks for a place to deploy it?
Ultimately, this is one of the great values that cloud computing provides in its ability to create infrastructure — networks, servers, etc — in minutes. Our AWS experts rely on CloudFormation templates to define, configure and provision these infrastructure resources, allowing us to effectively support a fast, reliable CD pipeline. Now, when we change a CloudFormation template, CodePipeline can automatically initiate a workflow that will build a test stack, test it, await manual approval when/where needed, and push the changes to production.
This keeps our IaC flowing smoothly and benefiting the entire system through greater consistency and security, and easier version control which allows for enhanced control over a fast, reliable code pipeline.
For example, we recently did work for a Fortune 500 manufacturer where we set up infrastructure as code. In doing so, Flux7 was able to decrease the time for server procurement to mere minutes. To fully enable its team to take advantage of this level of automation with the infrastructure, Flux7 setup scripts for bootstrapping the company’s MongoDB cluster. The result: a process which initially took the DB admin days, was reduced to 15 minutes.
In the case of this customer, we could now use CodePipeline to build a CD workflow by building a pipeline for CloudFormation stacks. We can choose CloudFormation-specific actions within a pipeline, such as creating, updating, or deleting a stack. And, we can establish a workflow that automatically builds a test stack when we submit an updated CloudFormation template. After AWS CloudFormation builds the test stack, we can test it and if approved, push the changes to a production stack, further streamlining the process.
By further automating and optimizing the code pipeline as a delivery mechanism of value, CD can bring a variety of benefits including lower development costs, higher quality results and faster times to launch. If you are interested in exploring further how AWS and CD can serve as a cornerstone for your DevOps initiative, give us a call today. We’re happy to assess your situation and how tools like CloudFormation and CodePipeline can play an integral role in bringing automation and IT modernization to your environment.
Continuous delivery of infrastructure with CloudFormation implies the following workflow: The CloudFormation templates are saved in a version control system. If a user wishes to create a change to the infrastructure, they clone the current template, make a change, review the change, and push the template back to the code repository. The CI/CD tool detects the new change, and triggers an update of the CloudFormation stack with the new change. Historically, the tool that we have used for implementing CD with CloudFormation is Jenkins. While the solution with Jenkins works well, we were keen to hear that AWS has announced an update to CodePipeline, with the ability to now build CD workflows for CloudFormation Stacks. We can now implement CD of infrastructure using a hosted service instead of maintaining our own Jenkins instance in AWS.
As heavy AWS CloudFormation users, we couldn’t wait to dive in and look in more detail at AWS’s news on how the new CodePipeline update would work with CloudFormation.
What does this mean? Together, the two technologies allow us to automatically build and test changes to AWS CloudFormation templates before they are promoted to production. While automation is core to building continuous delivery, it’s important that this update allows us to automatically build, test, and deploy code every time there is a code change, as based on our defined release process. However, most release processes also include manual approval steps — say before promoting to the production environment. So, the new update also easily facilitates these manual steps, keeping track of where we are at in the process and automatically moving on to the next step once the manual step is finished.
Two things that we really like about the new CodePipeline update are that it allows us to make further use of Infrastructure as Code and it allows us to rapidly and reliably make changes to our client’s AWS infrastructure, furthering the benefits of CD. Combined, these two are powerful. Let’s explore:
Ideally, CodePipeline delivery operates like brakes on a race car, giving you the control you need in order to go faster. However, for code to move through the pipeline at speed, the supporting infrastructure needs to be created and configured at a similar pace. After all, what good would speedy code delivery be if you had to wait days or weeks for a place to deploy it?
Ultimately, this is one of the great values that cloud computing provides in its ability to create infrastructure — networks, servers, etc — in minutes. Our AWS experts rely on CloudFormation templates to define, configure and provision these infrastructure resources, allowing us to effectively support a fast, reliable CD pipeline. Now, when we change a CloudFormation template, CodePipeline can automatically initiate a workflow that will build a test stack, test it, await manual approval when/where needed, and push the changes to production.
This keeps our IaC flowing smoothly and benefiting the entire system through greater consistency and security, and easier version control which allows for enhanced control over a fast, reliable code pipeline.
For example, we recently did work for a Fortune 500 manufacturer where we set up infrastructure as code. In doing so, Flux7 was able to decrease the time for server procurement to mere minutes. To fully enable its team to take advantage of this level of automation with the infrastructure, Flux7 setup scripts for bootstrapping the company’s MongoDB cluster. The result: a process which initially took the DB admin days, was reduced to 15 minutes.
In the case of this customer, we could now use CodePipeline to build a CD workflow by building a pipeline for CloudFormation stacks. We can choose CloudFormation-specific actions within a pipeline, such as creating, updating, or deleting a stack. And, we can establish a workflow that automatically builds a test stack when we submit an updated CloudFormation template. After AWS CloudFormation builds the test stack, we can test it and if approved, push the changes to a production stack, further streamlining the process.
By further automating and optimizing the code pipeline as a delivery mechanism of value, CD can bring a variety of benefits including lower development costs, higher quality results and faster times to launch. If you are interested in exploring further how AWS and CD can serve as a cornerstone for your DevOps initiative, give us a call today. We’re happy to assess your situation and how tools like CloudFormation and CodePipeline can play an integral role in bringing automation and IT modernization to your environment.
Subscribe to our blog
