- [Raf] So far, you have learned about some concepts in a CI/CD journey, starting with the dev aspects, and moving towards the ops part of the operation. You should be familiar with this graphic, which represents a complete DevOps journey for a given application. In this video, Alana and I will talk about some things you need to take care of in order to facilitate the smooth transition between the end and the beginning of this feedback loop. Let's say you applied everything you learned so far, and you have an application created via CloudFormation and orchestrated via CodePipeline. If you have that, it is likely that you will have it updated whenever pushes are made to the CloudFormation template, hosted on CodeCommit. Although that's awesome, I have a question for Alana. Alana, how would you try to predict a failure due to a hidden bottleneck? - [Alana] Good question. Let's consider a few examples to visualize that problem. Imagine that you modify your CloudFormation template to separate your environment into different VPCs. So instead of a couple of VPCs, you now may want to use tens of them. Or perhaps your Lambda functions are working pretty hard and you want to increase the maximum concurrent executions. Well, if you leave everything on the defaults for your AWS accounts and had never requested a soft-limit increase, this update stack operation would potentially fail because there's a limit on the number of VPCs you can have in a Region, as well as the number of concurrent Lambda function executions. Depending on how you have your CI/CD configured, that stack update failure could prevent other developers from pushing changes until it's resolved. Now, there is an AWS service called Service Quotas, which gives you a list of the AWS default quota value and the applied quota value in your AWS account. It's always worth checking if you're increasing capacity of a given resource. Of course, you can also do API calls to Service Quotas to get these numbers programmatically, which might be instrumental to incorporate in the build part of your pipeline. So, let's say you're not facing any limit issues in an update stack operation. What about other things that could break the flow? - [Raf] Great question, Alana. For the sake of having everything going smoothly with CloudFormation at the end of your CI/CD, I would like to talk about an important feature, CloudFormation change sets. There are three ways to change an AWS environment created by CloudFormation. The first one is directly touching the resources, which you should avoid doing, and you will understand why later in this course. The second method is updating the stack directly. And the third one, which is a little bit more sophisticated, is by using that CloudFormation feature called change sets. The advantage of change sets is that you can predict, a little bit, the result of an update stack operation by having CloudFormation telling you what will be changed. So you can double-check if that's really what you want before proceeding. Here, you can see the JSON that was generated by submitting a modified template that removes an EC2 instance and adds an Auto Scaling group with a launch configuration. It is pretty simple to understand. It gives you what will be changed in the section, Changes, of the JSON. And here, you can clearly see that two resources are being added and one is being removed, which is the EC2 instance. It is always a good idea to use CloudFormation change sets for production environments. Once you have an original stack running, you submit a change set, view the change set. If everything looks good, you can execute the change set. Otherwise, you do additional change sets or cancel the entire operation. - [Alana] All right, smooth operator. Let's move on. You ready, Raf? - [Raf] Yeah, I'm ready!
