A Practical Guide to Surviving AWS SAM
Part 4 — Release Change
It’s time to start talking about release change, one of my favourite topics but also the one that, over the years, caused me the most problems. There are so many ways to build, deploy, configure and parametrize an application, each with its pros and cons that is really difficult to take the right direction on the first try.
I anticipate you that doesn’t exist the silver bullet of release change, you have to pick what fits your expertise, knowledge, and organization, but I’ll try to give some tips and tricks that I have found to be really helpful. We will not cover all the aspects in this chapter but you can follow me on Medium and Twitter for updates.
With release change, I mean the act of moving code from source repository till production passing various steps, environments, and tests in the most automatic way. We can summarize this process with the well known CI/CD nomenclature Continuous Integration, Continuous Delivery, and Continuous Deployment.
As you can see in this image, you start with automating a build procedure, then you automate deployment to production but still with a manual approval step (you have to beat Gandalf), and finally, when your team has gained enough confidence and the test suite is mature, you can remove this manual step and let everything be automated.
Don’t ever try to reach continuous deployment from the beginning. Start with small steps and see what your needs are and the benefits of the solution. Maybe you will never reach the final stage due to complex tests or organizational barriers but for sure, you can still benefit from automation.
It’s never easy to start automating things because you would like to have something flexible but also that follows strict procedure, stable and fast but also secure. I think that one of the first drivers that runs your decisions, besides organization and technological stack, can be the Git management strategy. P
ersonally I’m a huge fan of Git Flow with its newer facet of Gitlab Flow. I have always found Trunk Base development as too complex for my use cases. I never really understand how multiple environments can live on the same branch with the release pipelines. On the other hand, I find the pair between branches and environments really easy to be used with CI/CD pipeline. Sure having branches may lead to merging nightmares and other problems but with some simple rules, you can really benefit from all these branches.
But let’s jump to the fun part. How can you use SAM to automate all these tasks? As you will see, part of the work is the same as what you have already done in the previous chapters. You will see two different approaches. In the first case, you will use SAM to build, package and deploy the entire application, all seamlessly embedded in CodePipeline and CodeBuild. The second approach instead will use SAM to build and package the application while the deployment will be performed by CodePipeline with the managed CloudFormation deploy action leveraging SAM compatibility with CloudFormation. As usual, on my GitHub page, you can find all the code.
SAM deploy pipeline
The release pipeline for SAM build, package and deploy is really easy. A step to source and check out your code managed by CodeCommit followed by a step of building and deployment managed by CodeBuild all orchestrated by CodePipeline. The world of Code* services is the developer suite for building CI/CD pipelines on AWS, and if you are new to these services, you will be happy to hear that they are all Serverless. And it’s also a Serverless service that is used to pass artifacts between stages, S3.
Here you can also find the CloudFormation template to build this pipeline, It’s not the easiest template that you may have seen but take some time to analyse it, I think that the tricky part can be the definition of roles and assume role policies if you are not used to CloudFormation role definition. But I don’t want to go deep into the details of it because is not the focus of this article, if you are a beginner to CloudFormation you can still deploy the stack and then explore it from the console, it’s always better to start with a graphical tool.
I want instead to keep your focus where the magic of this pipeline happens — buildspec.yaml, the file used by CodeBuild to describe actions to be performed as a list of bash commands to be executed. Nothing new here the usual sam build and sam deploy commands that you have already executed in your local environment, now embedded in a pipeline that will be automatically triggered on Git push to sync your Cloud environment.
The CloudFormation of the pipeline will be also in charge of creating a new CodeCommit repository where you can load the code and template of the well known hello-world application and the buildspec.yaml file with CodeBuild specification on the newly created repository.
Now if you push changes to CodeCommit the pipeline will start automatically deploying SAM application on your AWS account creating a new CloudFormation stack. Each subsequent push will update the stack according to SAM template specification
If you need to debug, clicking Details will directly redirect you from the pipeline to the CodeBuild project with configurations and logs.
CloudFormation deploy pipeline
The second pipeline share part of the definition with the previous one, but this time build step will execute sam package command instead of sam deploy because deployment will be performed by managed CloudFormation action in the pipeline.
This pipeline seems more complex but gives also great flexibility. First just looking at the pipeline you have the evidence of which step may be failed without having to look at logs. Second, with this pipeline, you can control the deployment. For example, you can add a manual step before deploying the application; or maybe, if you want to execute some test in the build stage without deploying the application, you can disable the transition and only when you are confident, re-enable the transition to synchronize Cloud environment.
You can even break the deployment to check actions that will be performed. CreateChangeSet step will create a CloudFormation change set that you can review and then you can execute DeployChangeSet in charge of change set execution updating CloudFormation Stack.
Here you can find the CloudFormation template for the pipeline and is almost the same as before, you just need to add the code for the two new steps and move some permissions from CodeBuild role to CodePipeline role, also if you look at the buildspec.yaml file it’s the same without sam deploy command. Now packaged.yaml artifact will be used by CloudFormation action to update the stack picking packaged code from S3 bucket, you can see this relation in the template of the pipeline
Also, the repository structure is the same.
And as before, every push on the repository SAM template configurations will be applied on the AWS account with a CloudFormation stack. But this time, you have a visual representation of what’s happening directly from the pipeline interface.
As you can see, with respect to the first solution architecture, complexity is almost the same but flexibility and control have improved.
Before the conclusion, I just want to give a useful tip. If you don’t want to have CloudFormation zombies stack, always delete in the order of the SAM stack and only after pipeline stack. Otherwise, you will need some workaround to delete the SAM stack. Also, never give SAM the name of an existing CloudFormation stack, otherwise, you will end up with the unpleasant situation where SAM overwrites your stack.
This topic is really huge and includes other topics like parameters management, test execution, multiple environment management (where you will see the benefits of Git Flow and branches). But we will address these topics in the next chapters.
More content at bip.xTech
