Automating Perl deployments with Hudson

Automating Perl deployments with Hudson
Automate testing, builds and deployments of Perl-based modules and full web applications

What’s Continuous Integration?
Speeds up development cycles by simplifying the integration and testing of software
Great for single- and multi-person teams:
Centralize testing to fix “Works in my environment” problems
Ensure testing actually happens
Lets everyone on the team know what’s happening

What’s it give you?
Instant notification of build failures due to
Broken code
Changed APIs
Additional surprise dependencies
Forgotten files and missing features
Notification of when changes occur
Always provides an available build for testing
Ensures all tests are run every time, even if it’s inconvenient

Why doesn’t everyone do it?
Most big shops do, or should
It’s typically a pain to set up and configure
Most people think “I won’t need it, I’m just a single developer”

That’s nice, how do I set it up?
Roll your own (major pain)
Use an existing tool
Hudson
CruiseControl
Bamboo
CABIE (Perl-based)
Autobuild (Perl-based)
Tinderbox (Perl-based)

…I went with Hudson
Easy to install and configure
A ton of pluggable modules
It “Just Works”
It’s easy to integrate into any project type using custom build scripts

Build history
Testcase history

That’s nice, what does it do?
Via a post-receive hook in Git, it pushes a Webhook call to Hudson
This triggers a build
…which pulls down the latest source into a workspace on Hudson
And then runs each of the steps in the build configuration (e.g. my build script)

That’s nice, what does it do?(cont)
The build script:
Cleans its environment from the previous run
Runs Makefile.PL
Runs make
Runs unit tests, with coverage
Converts the TAP test output to JUnit-style XML
Builds an distribution tarball

That’s nice, what does it do?(cont)
Finally, Hudson archives the “Build Artifacts” (the distribution tarball) as well as the coverage data
Notifies via email, Jabber/GTalk, etc if the build was a failure or a success
Updates the dashboard to show its result

Selenium System-Test Automation
Easy to run things other than unit tests
Hudson has a built-in module for the Selenium Grid to manage your Selenium servers
Trigger deployments to staging or production servers
Automatically push updates to CPAN if the build is “Parameterized” as a release build
Etc.

Deploying code straight to production
If you have enough confidence in your code, why not deploy with every update?

Release early, Release often
With enough unit test and system test coverage, every submit should be considered “Release Quality”
If you find build and test breakages acceptable, then you’re working the wrong way
Why leave unused code sitting in Git/Subversion, instead of in the hands of your users?

What do I need to feel good about my code?
That’s really up to you
Near 100% unit test coverage
Devel::Cover is your friend here
System tests for things that are important to you
Selenium
WWW::Mechanize
An easy way to roll back a bad release

My plans for automated deployment
Copy build artifacts to a production server
Extract, re-run unit tests, and install into a stand-by workspace
local::lib or separate Xen image
Start up server in testing mode
Non-live stand-by database
Testing URL or port number
Run Selenium tests against the server

My plans for automated deployment (cont)
Switch server into production mode, but leaving it on a staging address
Switch back to using the real production database
Run non-invasive smoke tests against the real database

My plans for automated deployment (cont)
If all the testing stages are successful, switch the web server configuration (nginx, Apache, load balancer, etc) to direct traffic to the new server
Re-run smoke tests against the production URL (optional)
Provide an easy mechanism to quickly re-activate the previous server by redirecting traffic back at the old daemon

Rome wasn’t burnt in a day…
Wonderful thing is, you don’t need every component to be successful.
Can be organically grown as your code matures
You can build as much, or as little, as necessary

Learn from your mistakes
Failure is wonderful: it teaches you what you need to know
When something breaks:
Learn what the root cause was
Write a failing test to prove the desired behavior isn’t being met
Fix the code, and watch your test go green
Any future failures in that area should now be caught

To err is human, so get rid of them
Humans are messy, problematic, and error-prone
Eliminate humans from repetitious tasks, such as
Testing
Production deployments
Rollbacks
The more you automate, the less can go wrong unpredictably

Questions?