Table of contents
Choosing the right open source tool or solution for your particular use case can be challenging due to the wide range of options available on GitHub and other platforms. Help is always greatly appreciated, especially in the early stages of your automation journey when there are a lot of unanswered or unclear questions.
This blog will guide you through some basic things you need to take care of when choosing your toolset.
Let’s get into it! 🎯
Coding
When it comes to automation, the first and most important application you’ll need is a development environment. In my opinion, there are two tools that you should look into. Each has unique advantages, disadvantages and use cases:
While I love IDEA for infrastructure as code (particularly with Terraform and variable and module dependency support) and extensive Git support, VSCode has many more integrations to offer.
I prefer IDEA for Terraform-related and VSCode for PowerShell DSC-related coding.
Whichever you choose, try to learn as many shortcuts as possible to speed up your workflow. For most of the automation tasks, you won’t need anything else, because inline help for commands, documentation with markdown, Git integration, debugging and testing capabilities are almost completely integrated to get you started.
Consider subscribing to GitHub CoPilot (about $10 per month) which will significantly boost the speed of coding with code completion and help with documentation.
GitHub CoPilot decreases the time you need to invest in writing code and documentation.
And for the unlikely possibility that you’re lost and don’t know how to start writing code, just ask ChatGPT. It helped me on numerous occasions – even when our developers were unable to do so. However, don’t expect too much; the solutions often don’t work completely and they need some tweaking. Sometimes, Google provides better examples.
Documentation
As mentioned in the last blog, documentation is essential for understanding the prerequisites and requirements of an automation script, as well as describing all functions and parameters.
The Markdown Guide gives you a good overview of the language. If you have a separate team that writes documentation for you, check Writerside.
Always store the documentation right next to your code to enable side-by-side changes with the code.
If, in addition to storing a README side by side with your code, you want to create a documentation web page for your team, check the following tools to create websites out of your Markdown code: Hugo and MkDocs.
Â
Implement change management and version control
Version control is the foundation of your automation journey, so make sure to implement a robust system for the future. You can start simply by creating one repository for your first script and then gradually extend capabilities the further your requirements and your knowledge grow.
A good starting point is Git. To not overcomplicate things in the beginning, create one repository on GitHub and make yourself comfortable with the features and possibilities. If you have an Azure DevOps subscription, you could also use Azure repos for that purpose. Depending on your use case, you should thoroughly examine your needs.
At XOAP, we initially moved away from Azure repositories since GitHub provides far more flexibility and extensions for change management, versioning, documentation and change deployment.
Â
Define development and coding guidelines
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 of your project sources are clean and correctly formatted.
Implement tfsec to enhance the security of your Terraform code during the 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 or 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 the 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.
Tool definition
This is highly dependent on your needs and is one of the most difficult ways to avoid getting into vendor lock-in at some point. While it may seem easy to use everything your preferred vendor or cloud provider supports and offers, it becomes more difficult when something significant changes and you need to find a solution.
This is one of the reasons why we use Terraform for our infrastructure and one of the reasons I refer to it often. Pulumi is a great alternative in this space that you can consider if you have a strong developer base in your company.
It also highly depends on what kind of business you have. Are you supporting other companies or just your own? If you’re an MSP, pay close attention to the licensing of your tools and what’s allowed. For example, Terraform’s recent BSL changes caused a lot of trouble in some companies.
Open source licensing can change – we’ve seen this several times. Keep this in mind.
Which infrastructure layer do you want to automate? XOAP distinguishes between Image Management, Platform Management, Configuration Management and Application Management. Each layer has its own subset of tools that you can use to support it.
I’ll help you get started without going into details. Some of the tools mentioned above can support multiple layers, but I’ve added them to the layer that seems most suitable.
Image Management
Platform Management
Platform independent
Platform-specific
Configuration Management
Application Management
The following tools are application packaging tools that always need some sort of vehicle installed on nodes. For Linux-related application installations refer to the Configuration Management tools.
Final thoughts
There are many other topics to cover, including staging, pipelines, monitoring, logging, security and details about Scrum and Kanban. I’ll cover this in detail some other time. For now, I hope the information above helps you understand the implications and what to look out for in your journey.
Loved this blog? Share it with a fellow IT automation enthusiast. 🙌
Â
Image by Freepik
