The benefit of sketching out your integration/deployment process (the sequence of steps), is that you are forced to start with the general and then define the detail. It is more intuitive to define the sequence of steps as a series of tasks (code, commands) and transitions (of state, authority, completeness, etc). The more tasks and transitions that can be safely automated the more ‘continuous’ the integration of changes to production will be.
Setting up your environment for Ansible module development is relatively straightforward, but there are some things which will make it easier to develop higher quality modules.
Rotating application layer passwords is hard. Not because changing a password in some database is difficult, it’s often only a single command. The hard part is doing a hundred password rotations, perhaps on a daily basis, in tiered applications, with change control, compliance, auditing, etc, etc.
One of the perils of Agile development is rooted in the belief that progress should be measured by change and newness. Far be it for me to assume the persona of Moros, but I have a sense of déjà vu. Back in the days of ‘physical tin’ we’d regularly find forgotten yet business-critical applications churning away on PCs under vacant desks. The application owner had long since left the company, and with them any hope of identifying what the PC was actually doing or its login. VMs and containers are even easier to leave behind.
I confess that I was not excited about the idea of unit testing Ansible roles. Roles written in the minimalist sense should fail early using the Ansible framework. A service is either present or not, and Ansible will tell you. To add extra layers of testing seems to introduce complexity and duplication, which may itself fail.
While working on a recent Ansible project I think I realised why roles are both fantastic and deadly. It’s not the syntax, it’s the semantics. And the problem comes from an evolution in the meaning and intent of Ansible roles.