This post will be the final one on the series about Infra-As-Code and I will keep this one short as we have covered a good bit over the past few weeks. So I will only be doing a quick overview of what we have covered in regards to methodologies and processes over this series. As well as I want to ensure that we finish up by reinforcing what we have covered.

Remember we will be adopting new ways of delivering services to our customers by taking a more programmatic approach which also should involve testing and development phases (something new to most right?). At the initial phase of a new request we should have an open discussion with everyone that should be involved in the duration of the new implementation. This open discussion should cover the specifics of a test plan and when a reasonable timeline should be reached. We should also be leveraging version control for our configurations and/or code and we accomplish by using Git repos. To further benefit our version control we should adopt a continuous integration/delivery solution such as Jenkins. By using a CI/CD solution we are able to automate the testing of our configuration changes and receive the results of those tests. This not only saves us the manual tasks that can be somewhat time consuming but also ensures consistency of our testing. And when we are ready for sign-off to move into production we should leverage a code-review system and peer review. Code-review adds in an additional layer of checks against the configuration changes we intend on making. And our peer review is for us to have a follow-up open discussions covering the results of our testing and development phases with those who were involved in our initial open discussion. And once we have final sign-off and all parties are in agreement on the deliverables we can leverage the same CI/CD solution as we did in our test/dev phases to ensure consistency.