workflow

For many new Ansible-based projects, I build my tests in Molecule, so I can easily run them locally or in CI. I also started using GitHub Actions for many of my new Ansible projects, just because it's so easy to get started and integrate with GitHub repositories.

I'm actually going to talk about this strategy in my next Ansible 101 live stream, covering Testing Ansible playbooks with Molecule and GitHub Actions CI, but I also wanted to highlight one thing that helps me when reviewing or observing playbook and molecule output, and that's color.

By default, in an interactive terminal session, Ansible colorizes its output so failures get 'red' color, good things / ok gets 'green', and changes get 'yellow-ish'. Also, warnings get a magenta color, which flags them well so you can go and fix them as soon as possible (that's one core principle I advocate to make your playbooks maintainable and scalable).

After reading A successful Git branching model [nvie.com], which I consider one of the best graphical/textual depictions of the ideal Git model for development teams (and most large projects), I simply wanted to adapt a similar (but way less complex) model for some of my smaller sites and multisite Drupal installs.

Since I'm (almost always) the only developer, and I develop locally, I don't want the complexity of working on many branches at once (master, hotfixes, develop, release, staging, etc...), but I do want to have a clean separation between what I'm working on and the actual live master branch that I deploy to the server.

So, I've adopted a simple 'feature branch model' for my smaller projects:

• master - the live/production code. Only touch when merging in a feature or simply fixing little bugs or really pressing problems.
• [issue-number]-feature-branches - Where I work on stuff.

Graphically:

Just posted for my own reference - here's my workflow for updating a D6 (probably also D7) website using drush. Comprehensive information about all drush commands can be found on the http://drush.ws/ website. If you're not yet drinking the drush kool-aid, you need to—if you use a Linux server, of course.

1. Visit admin/reports/updates page on your site, read through any relevant release notes for required updates (to check if there are special requirements for said update).
2. $ drush @site pm-updatecode <module1_shortname> <module2_shortname> (add all modules to be updated)
3. $ drush @site updatedb (updates the site database - update.php)
4. $ drush @site cc all (clears all caches on the site)

The reason I do this manually, instead of running something like pm-update or pm-updatecode is that I like the granularity and security of doing all the updates discretely—especially when I'm updating a larger site, where I like to know exactly what's happening when I update.