The following post is an excerpt from chapter 11 in my book Ansible for DevOps. The example used is an Ansible role that installs Java—since the role is supposed to work across CentOS 6 and 7, Fedora 24, Ubuntu 12.04, 14.04, and 16.04, and Debian 8, I use Docker to run an end-to-end functional test on each of those Linux distributions. See an example test run in Travis CI, and the Travis file that describes the build.
Note: I do the same thing currently (as of 2019), but now I'm using Molecule to tie everything together; see Testing your Ansible roles with Molecule.
Last night I presented the following slides at the Ansible St. Louis meetup at Riot Games. In the presentation, I mention the motivation behind Ansible and Galaxy 2, and run through most of the major changes and new features:
I've incorporated many of the new features in Ansible 2.0 in my book, Ansible for DevOps, and will be rewriting a few of the examples in the book to take advantage of new features in Ansible 2 soon!
In the middle of preparations for next month's Souls & Goals soccer match, I've also been very busy with Ansible-related activities.
I'm still making progress in writing Ansible for DevOps (over 45,000 words, and over 900 people have already bought the book on LeanPub!), and I've been invited by the folks at Professional VMWare to present in their #vBrownBag DevOps Series! I'll be talking about Ansible for an hour or so, and I'll be sure to post the link to the presentation after it's over.
You can join the presentation live (starts at 7:30 p.m. CST tonight, October 29) by registering at http://professionalvmware.com/brownbags/.
I presented an introductory session on Ansible and how it can power Drupal infrastructure management and deployments at DrupalCon Austin 2014. Video and slides from the session, titled DevOps for Humans: Ansible for Drupal Deployment Victory!, are embedded below:
I'm still recovering from an intense week of Drupal here in Austin, TX. I kicked things off by walking around the downtown area, then taking the intensive Acquia Drupal Developer Certification exam. Once the conference started, I attended a few sessions, met a few awesome Drupalists, and learned a lot. On the last day of the 'Con (the last session, in fact), I presented DevOps for Humans: Ansible for Drupal Deployment Victory!.
I think the presentation went well, and I heard some great questions at the end which really contributed to the discussion of Ansible and Drupal deployments in general. It was a great way to finish up the official DrupalCon sessions, though it meant I was revising slides for the hundredth time during the rest of the week, instead of relaxing and enjoying DrupalCon!
Before I post a video and slides from the session, I wanted to highlight some resources for anyone who attended (or didn't attend) DrupalCon Austin:
- Extended sprints are still going on—join up and help make Drupal better!
- All the session videos are available on the Drupal Association's YouTube Channel. The videos are also embedded in each session's page on the Austin 2014 website. Here's a list of all the sessions.
- Check out future DrupalCon info: DrupalCon Amsterdam 2014, DrupalCon Latin America 2015, and DrupalCon Los Angeles 2015.
- If you attended the Palantir-sponsored Trivia Night, here are all the teams' final scores (my table got 9th, with 3 DrupalCon first-timers!).
Below is the video and slides from the DevOps for Humans presentation. Please let me know what you think!
I've published the first portion of a book I've been writing, Ansible for DevOps. This is my first-ever book, and I've written a little about the process of writing on Server Check.in's blog: Self-publishing my first technical book on LeanPub.
I'm excited about the early feedback I've already received—and I haven't even finished writing half the book! I'm hoping to finish the first complete draft of the book (and continue publishing it in stages on LeanPub) by summer 2014.
tl;dr: Get the Vagrant profile for Drupal/PHP Continuous Integration Server from GitHub, and create a new VM (see the README on the GitHub project page). You now have a full-fledged Jenkins/Phing/SonarQube server for PHP/Drupal CI.
In this post, I'm going to explain how Jenkins, Phing and SonarQube can help you with your Drupal (or hany PHP-based project) deployments and code quality, and walk you through installing and configuring them to work with your codebase. Bear with me... it's a long post!
If you manage more than one environment (say, a development server, a testing/staging server, and a live production server), you've probably had to deal with the frustration of deploying changes to your code to these servers.
In the old days, people used FTP and manually copied files from environment to environment. Then FTP clients became smarter, and allowed somewhat-intelligent file synchronization. Then, when version control software became the norm, people would use CVS, SVN, or more recently Git, to push or check out code to different servers.
All the aforementioned deployment methods involved a lot of manual labor, usually involving an FTP client or an SSH session. Modern server management tools like Ansible can help when there are more complicated environments, but wouldn't everything be much simpler if there were an easy way to deploy code to specific environments, especially if these deployments could be automated to either run on a schedule or whenever someone commits something to a particular branch?
Enter Jenkins. Jenkins is your deployment assistant on steroids. Jenkins works with a wide variety of tools, programming languages and systems, and allows the automation (or radical simplification) of tasks surrounding code changes and deployments.
In my particular case, I use a dedicated Jenkins server to monitor a specific repository, and when there are commits to a development branch, Jenkins checks out that branch from Git, runs some PHP code analysis tools on the codebase using Phing, archives the code and other assets in a .tar.gz file, then deploys the code to a development server and runs some drush commands to complete the deployment.
Static Code Analysis / Code Review
If you're a solo developer, and you're the only one planning on ever touching the code you write, you can use whatever coding standards you want—spacing, variable naming, file structure, class layout, etc. don't really matter.
But if you ever plan on sharing your code with others (as a contributed theme or module), or if you need to work on a shared codebase, or if there's ever a possibility you will pass on your code to a new developer, it's a good idea to follow coding standards and write good code that doesn't contain too many WTFs/min.
For the past few years, as the number of servers I manage has increased from a few to many, and the services I operate have required more flexibility in terms of adding and removing similarly-configured servers for different purposes, I've been testing different deployment and configuration management tools.
Many developers who are also sysadmins have progressed much the same way as I have, beginning by building everything by hand without documenting the process, then documenting the build with text files, and ultimately scripting builds with bash scripts. However, none of these techniques allow fast provisioning, continuous configuration management, or the flexibility required to make constantly-evolving applications adapt to the requirements of the day.
In recent years, 'DevOps' (better integration of development and operations) has become a hot buzzword and mantra of companies espousing agile development methodologies.
A Very Brief (and woefully inadequate) Philosophy of DevOps
Servers, like instances of applications, should be managed via version-controlled configuration, and should be disposable (a common war cry: Trash Your Servers and Burn Your Code. If a server blows up, or if another few application servers are needed, they should be able to be provisioned or decommissioned in minutes, not hours (much less days or weeks!), and should be able to be provisioned and decommissioned automatically, without human intervention.