#5 Continuous Integration
This is the fun stuff! The concept of Continuous integration is easy. Once you are done writing the code you want it to be deployed into production / QA as soon as possible in a automated fashion. You can also use the same automation that is deploying your code to first act as a gate keeper to ensure that all your defined standards are enforced and any code that is out of compliance with your defined standards is flagged and possibly rejected. A good continuous integration solution will save you a lot of time as it will reduce the time to manually deploy solutions and prevent the errors that come along with doing so.
Besides the glory of automating your code deployment a well-developed continuous integration solution makes it possible to keep all of your development environments (QA/UAT/DEV) in sync with a matching branch of code by deploying to the environment as soon as changes are checked into the branch of the repository. For deploying changes to production you can follow the same process as UAT but ensure that a valid and approved change order exists. Scripting an integration to any modern ticketing system is usually well documented by the vendor using some form of vendor supplied API. I highly recommend utilize your existing service management (ticketing) tooling whenever possible, especially when it comes to change control.
Types of Continuous Integration
A passive contiuous integration solution looks for changes periodically using a script or service that runs on an interval. If any changes are found in the source control repository, pull the changes and deploy them to the appropriate environment(s).
Example - 1. A pull request is approved and changes for a SMA runbook are merged into the QA branch of the repository. 1. A scheduled tasks will query the repository for changes to any branch on the repository on a regular interval (maybe every 15 minutes). 1. When changes are found containing a new or modified runbook, validate the changed code meets all agreed upon standards and then deploy the new code into SMA. 1. Log this process extensively for an easy audit trail and perhaps more importantly a nice report at the end of the year reporting on how many code pushes were made to different branches saving this specific amount of time.
When changes happen to the contents of a specific branch of the repository the repository can send notification of the activity the form of a webhook. The message is sent to a listening endpoint (a web service or API) and that endpoint could, based on the contents of that message, kick off a task on using some form of Autoamtion Engine like SMA or Azure Automation.
The web hook is usually a JSON payload sent to a listening web service like Jenkins, or a simpler home grown web service. Simple one here. The payload contains all the changes made in the latest commit and the webservice will either act on the payload itself or forward it on to something like an SMA or Azure Automation runbook for action.
Example using Service Management Automation (SMA)-
1. A pull request is approved and changes for a SMA runbook are merged into the QA branch of the repository.
1. A web hook message containing a JSON payload with all of the details of the change is sent to a listening web service from the repository.
1. Pass on the relevant information from the payload as a parameter to a runbook. 1. The runbook investigates the change to ensure code quality and standards. 1. The updated runbook code is deployed to the QA SMA environment.
Most source control solutions provide this type of webhook functionality. (GitHub, GitLab, VSTS, and surely many more).
More things to do with CI * Ensure that Pester unit tests exist for the code with at least 90 percent code coverage * Ensure the script passes all PS Script Analyzer rules. * Email everyone with the new changes and post to Slack, Yammer, etc. * Log high level details to a centralized logging solution for later reporting.