Now that we've got a better idea of what an automated pipeline looks like, let's take a look at triggering the pipeline via a code change instead of pressing a button.
This is how the pipelines will be trigger 95% of the time: when someone makes a change. That's the primary reason we create these pipelines and it's the overall goal of DevOps - to automate the delivery of changes once, as an organisation, we're happy that our tests and processes are good enough at catching problems.
We'll cover the theory of automating everything end to end in a later phase of the book's development.
Our Terraform code is in a working state at this point in time so instead of making a change that actually changes some infrastructure, we'll make a change that simply triggers the pipeline. For this we can just add a comment to a Terraform file.
It might be possible to further enhance a pipeline to improve it's ability to detect actual changes to the code, not just comments, but that's not within our scope right now.
Let's edit the
main.tf file and add a comment to the top of it. Don't worry we're also going to remove the comment again to trigger the pipeline a second time, just for good measure.
1 2 3
Now we're going to save this file to disk and commit it:
git commit -m 'adding comment to trigger pipeline' main.tf
Now head over to the
infrastructure/terraform repository and check the pipelines page. You will see that a pipeline has started:
For me this pipeline completed and then waited for me to trigger the
apply stage, which I did not do. In fact I actually deleted this pipeline for the same reasons I've discussed previously: prevent accidental (or otherwise) running of the pipeline.
What we've done here is successfully triggered the pipeline by changing a
.*tf file which results in our rule:
Being considered true and therefore the stage is included in the pipeline, which then runs each stage in order.
Undoing the Change¶
My advice now would be to delete the comment we added to the file, commit the results (an operation you should be able to do at this point), push them and watch a second pipeline get triggered. I'd recommend deleting this pipeline too unless you want to experiment.
Now we're going to build the application CI/CD pipeline so that we can automatically build new release as and when we change the code.