I attended DrupalCamp Asheville this weekend and got too much information, too quickly to take notes on it all. Most of what I listened to was about continuous integration and performance. I've re-capped some of the presentations and added some of my own related findings.

Continuous Integration

notzach showed off how he does some of his site build and installation processes using git, Jenkins, Fabric, and Aegir. He configured Jenkins to watch the OpenBlog project for new commits. When Jenkins sees a new commit, it will download the project, run tests on it, then deploy it to two different servers using two sub-tasks that cascade from the original build. If at any point during the process there is an error, he gets notified.

On some points of workflow, which was largely mirrored by chriscalip, in the workflow of doing continuous integration with Jenkins, nobody found it practical or useful to run tests on core or contributed modules. Zach and Chris only ran tests in Jenkins were only run on modules managed by themselves. I have settled on the same conclusion for our testing at work. Even if most contributed modules passed, the additional processing time is undesirable. There's also a practical element of how much impact you can contribute back to fix broken tests that fail on projects you don't manage yourself.

Unique to chriscalip's approach was that he decided using PHPUnit was far better than Simpletest. Normally this might have not been practical, but he thought writing their own tests at promet on their custom modules in PHPUnit and ignoring Simpletests altogether was a satisfactory, if not superior, alternative to Simpletest.

For the longest time, I've been recommending people use what qa.drupal.org uses. That means using what the PIFR project uses, and in turn what the maintainers of it recommend. While Moshe recommends PHPUnit, the current situation dictates that Drupal will use whatever boombatower, jthorson, and rfay like, because they maintain PIFR and the qa server. None of the three is committing any more than their free time to the effort.

Git workflow

For workflow with version control, the consensus appears to be for developers to commit their work to a development branch. When development is possibly stable, merging that work into a test branch should be what triggers Jenkins to automatically build tests, launch the code to a test virtual machine, and clone a staging or live database to the test site.

I recommend for developers to create a new branch for the case they're working on. The name of each branch is prepended with the nid of the case from our Open Atrium case tracker. Having branches named "OA5347_add_views_cache" makes it possible to easily track the commits back to the originating task, describe what it was supposed to do, and if we ever change case tracker software, identify which case tracker website it came from even if the commit messages are poor. For post-merge tracking, each of the commit messages should still include the case number prefix to be able to link back to its source task on un-squashed merges.

One component that was missing in the presentations, and admitted to be a gap in the workflow by at least notzach, was formalized approval of the test site functionality. gerrit was the only code review, project management approval tool I've heard since DrupalCon Denver that seems to have a chance to fill the role other than some combination of Atlassian products.

Also missing was a way to manage multiple developers merging to the test branch in a similar time span, clobbering the previous one's test launch on the shared virtual machine. More complex deployments using virtual hosts and/or Aegir could likely resolve the clobbering issue from my understanding.

Performance

erikwebb made a presentation on performance not geared towards system administrators. In it, he informed and reminded about some common configurations that we often overlook when rushing to launch a site. There are some summary take-away points I think are good reminders when setting up a site:

• Don't install a module unless you really need it. Otherwise, you're just using more memory and adding to CPU time.
• Avoid using modules that set a global $_SESSION variable when you have a site of primarily anonymous visitors
• It can be cheaper to use tools like XHProf and XDebug to find the source of bottlenecks than to keep throwing hardware at a problem.
• We can't decide when a site is slow until we have a documented benchmark (e.g. 500ms could be acceptable, going over 1 full second is not). Set the standards and monitor them regularly. The "regularly" part can be done with Jenkins.
• Most modules default to not caching when it is an option. Blocks, Views, and Panels can cache, and with big benefits to authenticated users, but you have to turn it on per instance.
• If you edit content frequently, set a minimum cache lifetime for the site-wide cache unless the release time of a post is critical.
• Use a recent version of Drupal to get faster 404 pages if you have a lot of 404 requests.
• Entity cache and Path Cache appear to have only benefits and no downsides for helping load times.
• Views Litepager can help make Views faster when there are many pages to click through.

Most of these things are something a developer can manage, aside from the normal list of using APC, memcache, redis, varnish, etc. More on the system administration side, Erik showed off a library of Drupal JMeter tricks which he says can be integrated into a regular Jenkins build and graphed with relatively low complexity.

Join me at DrupalCamp Atlanta where I've committed to rolling all these findings into one presentation for your collective viewing as a live demonstration. I should, theoretically, be able to roll it all together and have the appropriate links, software, and documentation available to use as I build a server on stage. If you only see a slide show, you'll know I've failed.

Post categories

Drupal