Date post: | 18-Nov-2014 |
Category: |
Technology |
Upload: | nachbaur |
View: | 11,955 times |
Download: | 1 times |
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 occurAlways provides an available build for
testingEnsures all tests are run every time, even
if it’s inconvenient
Why doesn’t everyone do it?
Most big shops do, or shouldIt’s typically a pain to set up and configureMost 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 configureA ton of pluggable modulesIt “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 HudsonAnd 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 youNear 100% unit test coverage
◦Devel::Cover is your friend hereSystem 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 serverExtract, 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
databaseRun 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?