This section is pipeline inception. Wouldn't it be good if the pipeline only existed when we needed it? This would save costs and make our environments simpler. Often,  we will have a branch for a particular build or release candidate that we need to run tests on before merging it into the trunk branch. If you're following the GitFlow versioning and release strategy, release candidate branches have a limited lifetime and can be deleted once a release has been tagged and the branch has been merged. It would be great if we could set up some automation to do that process for us when we need it. 

The following is our GitFlow example for a release candidate (RC) branch that splits from the master and is then merged back after a few commits:

We can create a dynamic branch pipeline by using the awesome trigger features of CodeCommit. This feature allows us to add an SNS topic or lambda function for a particular action within a repository. This would allow the repository to notify a subscriber to an event or run some code to add value to a process in response to an event. In our case, we want a Lambda function to be invoked when a new release candidate branch is created so that we can deploy a CloudFormation that describes a pipeline. We also want to trigger the function when the branch is deleted so that we can then clean up our resources.

The following screenshot shows where we would set that up—the following screenshot shows the settings page of the CodeCommit console. In Triggers, we can see that two triggers have already been created:

The invoked lambda function could pull a CloudFormation template from source control and then deploy a new stack for a CI/CD pipeline with the correct configuration, so that it can link up to the release candidate branch. When the release branch is deleted, the same lambda will find the stack based on a predetermined naming convention and remove it. Pretty neat!

Here's what the process would look like. A developer pushes a new release candidate branch to CodeCommit, which triggers a lambda function. The function takes some input (such as the repository's details) and deploys a CloudFormation stack representing our pipeline:

The new pipeline would pull the code, build it (if required), package it, deploy it to a new stage or environment, test it, push a test report to storage, and then remove the environment altogether:

The process finishes when the developer merges the RC branch back into the master and deletes the branch. The pipeline is no longer needed. Because of the delete event, a CodeCommit trigger invokes a lambda function and passes the repository information. The function finds our temporary release pipeline and deletes the CloudFormation stack:

So there we have it—a pipeline that manages its own life cycle. I really like this example because the pipeline only exists for the time it is required. In addition to making better use of resources, you don't have to worry about the state or queued jobs, which you might have to with a shared pipeline. 

In this section, we have learned how to build a CI/CD pipeline that takes care of our serverless projects. Then, we learned about a more advanced approach that allows the pipeline to deploy and remove itself.