Because the change process always starts and ends with the developer (yes, you‘re now a developer), you should implement guidelines before the code even reaches the repository. There are a few tools out there you should look at.

The first one is pre-commit hooks. It checks the code against simple issues like missing semicolons, trailing whitespaces and more. The next thing you should have an eye on is the topic of linting with Megalinter. It analyzes the consistency of your code, IAC, configuration and scripts in your repository sources to ensure all de your project sources are clean and correctly formatted.

Implement tfsec to enhance the security of your Terraform code during les development of modules.

After these baselines, you need to check your desired change management flow. This one depends on your specific use case and what you want to deploy. Think about this!

Moreover, take a look at Git flow ou GitHub flow. Besides that, good versioning of your scripts and modules is crucial to track changes with your commits. You can use GitHub actions to automatically create updated versions when you create a pull request. Check out this semantic versioning document to know how version numbers should look like.

A good versioning system will greatly enhance production deployments, especially in IaC-related automation projects – by enabling more advanced control of modules and stacks.

Lastly, I have to mention les commit messages you or your colleagues enter when pushing a change to the repository or creating a pull request. This forces you to actually look into the code to check and approve changes. With that said, we should make our lives as simple as possible and reduce overhead.

There‘s nothing more annoying than reading something like “Fix” or Fix for fix” in the comments for a commit.

When starting with the creation of automation scripts, it’s important to introduce a version control system right from the beginning. This holds true even if you’re a single person working on the project.

You should consider creating a Git repository with a “master” and a “development” branch. This helps you to learn and practice the process of pulling code from a Git repository, pushing it back and creating a pull request to release it to the “master branch”. The “development“ branch is your development environment, and the “master“ branch is your production environment.

Don’t skip this if you plan to implement automation completely in your IT department and environment – this is the foundation of everything that follows. Implementation of components like automatic documentation, security scanning of code with linting or the pipelines you create to deploy your code will rely on les first basic version de control components.

Implementing Git also fosters collaboration as soon as you add more people to the automation initiative and enables more teams to collaborate. This implementation also encourages knowledge sharing and supports the documentation by adding operational changes to the complete development and delivery process.