As with developing code for an application, the process one manages and deploys their code for IaC resembles how developers have been managing their application code.

IaC starts with CND teams storing their IaC in a repo (for example, GitHub, CodeCommit, and BitBucket). Once in a repo, code can be tested, branched, developed, merged, and forked. This enables a larger team to continually work on and develop a stack in isolation without colliding on their contributions.

There exist native cloud services that cover every aspect of the code development process as follows:

For the AWS platform, the services that correlate to each of the preceding processes are as follows:

A more in-depth example of the AWS coding services is provided in Chapter 9, Amazon Web Services.

IaC can be validated using SDKs available from the CSPs for common IDEs such as Eclipse. Furthermore, tools such as cfn-nag from Stelligent can be used to automatically catch anti-patterns in your code before deployment. The project can be accessed at https://github.com/stelligent/cfn_nag. Cfn-nag can be used at the commit stage, meaning an IaC developer can receive rapid feedback before deployment. This can be inserted in your pipeline and prompt an exit code if any critical faults are found.

Services such as Amazon Code Pipeline provide users with an easy and managed continuous integration and continuous delivery service. Code Pipeline builds, tests, and deploys your code every time there is a new commit on your code repo or a web hook is activated. The deployment is handled by AWS CodeDeploy, which automates software deployment to compute targets available on the platform (such as EC2, AWS Lambda, and even on-premises virtual machines):

A mature cloud native approach for developing code could look like the preceding diagram. Developers create a code repo on Git. Once the code is reviewed, AWS CodePipeline tests and pushes to AWS CodeBuild, which compiles the source code, runs tests, provides software packages, and deploys to Amazon Elastic Container Registry (ECR). ECR then maintains copies of your container-based app, which are deployed to Amazon Elastic Container Service (ECS).

Once your pipeline has completed the process from commit/push to deployment, monitoring and tracking configuration becomes paramount to cloud operations. Creating custom logs and metrics that are pertinent to the particular app, service, or microservice built is key to maintaining stability in the long run:

• For an application, an example may be user request life time (how long have user-based jobs been alive in the queue)
• For a service, an example may be API-driven service requests for a query of how many friends a user has (such as a social network application)
• For a microservice, an example may be how many container requests are coming in from across the enterprise environment for the container orchestration microservice