This document discusses how to automate testing, builds, and deployments of Perl applications using Hudson. Hudson is an open source tool that facilitates continuous integration by automatically building code, running tests, and deploying changes whenever code is committed to version control. The document outlines how to set up Hudson to run tests and deploy code changes, providing notifications of failures or successes. It also discusses strategies for deploying code directly to production after passing automated tests to speed up release cycles.

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

2. 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

3. 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

4. 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”

5. 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)

6. …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

8. Build history Testcase history

11. 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)

12. 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

13. 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

14. 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.

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

16. 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?

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. Questions?