Developer experience for Ansible developers can vary significantly depending on the tooling they can access, the operating system they use, and the technical background they have. These variations have real-world implications for the quality of automation that is developed. With poor, untested code, automation adoption can suffer, stall, and eventually fail.
Imagine the ideal Ansible development experience: there should be seamless access to testing tools, linters, a user-friendly integrated development environment (IDE) experience, and integration with source control. All too often, there are administrative or technical blockers to creating this ideal environment, and that carries significant repercussions.
Field observations
There are two types of workarounds teams use to move towards this ideal development environment. Each tries to get the user access to standard tooling but also comes with its own drawbacks.
First, linters and testing tools are sometimes moved to a pipeline, like GitLab Runners or GitHub Actions. This approach creates a slower feedback loop, which makes development harder. While pipelines are an essential part of the CI/CD process, they shouldn't be the first place a developer realizes their automation, such as a playbook, has a linting error.
Another common workaround is pairing an IDE, often Visual Studio Code (VS Code), with an Ansible-equipped system through extensions like Remote - SSH, Windows Subsystem for Linux (WSL), Docker Desktop, or Podman. This requires varying degrees of overhead and opens the door to individual workstation discrepancies. In other words, "it worked on my machine." On top of this, acquiring and maintaining these tools in some highly regulated environments is almost impossible due to technical and administrative obstacles.
A new solution
The focus of this article is an opinionated development environment that gives users instant feedback, allows for easy testing, and is standard for all developers in an enterprise: a literal easy button for folks looking to get started. Red Hat OpenShift Dev Spaces recently released an Ansible workspace sample—an exciting step in an ongoing effort to create a smooth Ansible developer experience. This sample workspace is currently a community effort, and this post highlights its advantages.
Red Hat OpenShift users can test this out by installing the OpenShift Dev Spaces Operator (version 3.7.0 or later). For those of you who want to follow along at home, you can try it for yourself in the no-cost Developer Sandbox for Red Hat OpenShift.
Upon opening OpenShift Dev Spaces, you can select Ansible as your sample workspace, as shown in Figure 1.
Inside the sample Ansible workspace, there is the Dev Spaces IDE. Figure 2 shows the IDE with a playbook open in the top right frame. The playbook has a highlighted error from the Ansible extension and an open terminal to show installed Ansible.
Once you have the sample running in your browser, you can check out the following rich feature set provided in the workspace.
Powerful, modern IDE
OpenShift Dev Spaces supplies a VS Code-like editing experience that many developers find productive. It is highly configurable, with an extension library to support any development workflow. The Ansible VSCode extension is present in this IDE, which allows for instant syntax checking, linting, and autocomplete to accelerate development. You can add additional extensions for YAML syntax checking, Python development support, and many other capabilities.
Ansible CLI tools
Inside the Ansible workspace is a full developer toolset. The Ansible Dev Spaces sample comes loaded with the following CLI tools needed for development:
A user can run syntax checks, Ansible ad hoc commands, and playbooks from the environment, something that is currently impossible for some developers.
Ease of testing
The Molecule testing tool is provided in the sample workspace. Furthermore, running on OpenShift allows for the possibility of spinning up containers to test against in the cluster. There's even an example in the workspace, in /collections/.../roles/backup_file, where Molecule uses a custom driver to spin up a container, runs the playbook against it, runs tests, and then spins down. Developers can now access the ephemeral infrastructure to test the automation they are developing.
Consistent environment
Each workspace is centrally configured, removing the configuration drift that happens in environments with local workstations. This consistency gives developers confidence that if they get a clean run, so will their teammates. It also cuts down on-boarding time for new team members; with one click, they can have a setup that is identical across their enterprise.
Takeaways
The environment where users develop Ansible automation matters. Without proper testing and linting tools, development is much harder and slower than it needs to be. Over time, we've seen a number of solutions that users have implemented out of a need for this kind of tooling, which come with their own complexities and pain points.
However, as illustrated in this article, using OpenShift Dev Spaces as an Ansible development environment provides many advantages that help ease the process. The standardized environment removes setup time and workstation discrepancies and allows for dynamic and streamlined testing that utilizes OpenShift's strengths. While this is still an emerging, community-supported solution, you can apply these concepts as a baseline for increasing the overall velocity and experience of your automation journey.
You can try out these capabilities today using the no-cost Developer Sandbox for Red Hat OpenShift.
Last updated: March 11, 2024