This chapter will focus on determining a deployment strategy to meet your business requirements. We will look at the various options offered by AWS for deploying and updating your solution.
Choosing the right deployment strategy is paramount to successfully manage your solution stack and meet your business requirements.
This chapter will cover the following topics:
You might be wondering why you need a deployment strategy in the first place. A deployment strategy ensures that you can efficiently deploy new workloads and roll out new features or fixes for existing workloads, which is essential to any enterprise’s change management process. The deployment strategy is the key element in your change management process, because deployment is the element that most affects the speed, agility, and efficiency of your overall change management process.
Nowadays, numerous enterprises have adopted a DevOps culture to advance their change management process. Their objectives are to deliver software faster to production, reduce time to market, and improve software quality. Furthermore, as part of these objectives, they emphasize achieving a high degree of automation for deployment. Deployment is part of an end-to-end software lifecycle management process that, in an ideal DevOps world, consists of Continuous Integration (CI) and Continuous Delivery (CD), aka CI/CD.
CI involves improving software quality and delivering software updates faster. In this phase of the software lifecycle management, developers commit their code to a code repository, which then triggers a software build and a series of tests to verify that the expected quality is met. If the tests fail, the developer must address the identified issues. When the tests are passed, the process continues to the next stage, CD, which involves delivering new software releases into production faster and safer. Once the software has been built and tested during the CI stage, it enters the CD stage to be packaged and deployed into the relevant environments (for instance, Integration, User Acceptance Testing (UAT), and Production environments). This is where deployment takes place.
Before you deploy a new software release, you must decide how you’re going to proceed to actually roll it out in the target environment(s). First of all, do you intend to reuse any existing infrastructure for your workload, or do you consider your infrastructure to be immutable? DevOps advocates treating infrastructure as code (that is, taking an Infrastructure as Code (IaC) approach), so that you can manage infrastructure using the exact same tooling you used for software development, including development environments, source code repositories, testing tools, and so on.
Then, how do you want new releases of your application to be deployed? Do you want the new release to replace the pre-existing release all at once and in-place? Or do you want to progressively roll out new releases, updating your infrastructure in batches (aka blue/green deployment)? Alternatively, when you progressively roll out your new release, do you want to keep the pre-existing release up and running until you have verified that the new release works as expected (either canary deployment or linear deployment)?
How you answer the preceding questions will inevitably be influenced by your very own software development culture, which will vary from one organization to the next. In any case, answering these questions is the first step in determining your deployment strategy. For instance, you may opt to use immutable infrastructure with an IaC approach and then enforce canary deployment for every new software release in Production.
Once you have decided on a strategy, the next stage consists of deciding on the tooling to actually implement it.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
