Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Automating Perl deployments with Hudson


Published on

Automate testing, builds and deployments of Perl-based modules and full web applications.

Published in: Technology

Automating Perl deployments with Hudson

  1. 1. Automating Perl deployments with Hudson<br />Automate testing, builds and deployments of Perl-based modules and full web applications<br />
  2. 2. What’s Continuous Integration?<br />Speeds up development cycles by simplifying the integration and testing of software<br />Great for single- and multi-person teams:<br />Centralize testing to fix “Works in my environment” problems<br />Ensure testing actually happens<br />Lets everyone on the team know what’s happening<br />
  3. 3. What’s it give you?<br />Instant notification of build failures due to<br />Broken code<br />Changed APIs<br />Additional surprise dependencies<br />Forgotten files and missing features<br />Notification of when changes occur<br />Always provides an available build for testing<br />Ensures all tests are run every time, even if it’s inconvenient<br />
  4. 4. Why doesn’t everyone do it?<br />Most big shops do, or should<br />It’s typically a pain to set up and configure<br />Most people think “I won’t need it, I’m just a single developer”<br />
  5. 5. That’s nice, how do I set it up?<br />Roll your own (major pain)<br />Use an existing tool<br />Hudson<br />CruiseControl<br />Bamboo<br />CABIE (Perl-based)<br />Autobuild (Perl-based)<br />Tinderbox (Perl-based)<br />
  6. 6. …I went with Hudson<br />Easy to install and configure<br />A ton of pluggable modules<br />It “Just Works”<br />It’s easy to integrate into any project type using custom build scripts<br />
  7. 7.
  8. 8. Build history<br />Testcase history<br />
  9. 9.
  10. 10.
  11. 11. That’s nice, what does it do?<br />Via a post-receive hook in Git, it pushes a Webhook call to Hudson<br />This triggers a build<br />…which pulls down the latest source into a workspace on Hudson<br />And then runs each of the steps in the build configuration (e.g. my build script)<br />
  12. 12. That’s nice, what does it do?(cont)<br />The build script:<br />Cleans its environment from the previous run<br />Runs Makefile.PL<br />Runs make<br />Runs unit tests, with coverage<br />Converts the TAP test output to JUnit-style XML<br />Builds an distribution tarball<br />
  13. 13. That’s nice, what does it do?(cont)<br />Finally, Hudson archives the “Build Artifacts” (the distribution tarball) as well as the coverage data<br />Notifies via email, Jabber/GTalk, etc if the build was a failure or a success<br />Updates the dashboard to show its result<br />
  14. 14. Selenium System-Test Automation<br />Easy to run things other than unit tests<br />Hudson has a built-in module for the Selenium Grid to manage your Selenium servers<br />Trigger deployments to staging or production servers<br />Automatically push updates to CPAN if the build is “Parameterized” as a release build<br />Etc.<br />
  15. 15. Deploying code straight to production<br />If you have enough confidence in your code, why not deploy with every update?<br />
  16. 16. Release early, Release often<br />With enough unit test and system test coverage, every submit should be considered “Release Quality”<br />If you find build and test breakages acceptable, then you’re working the wrong way<br />Why leave unused code sitting in Git/Subversion, instead of in the hands of your users?<br />
  17. 17. What do I need to feel good about my code?<br />That’s really up to you<br />Near 100% unit test coverage<br />Devel::Cover is your friend here<br />System tests for things that are important to you<br />Selenium<br />WWW::Mechanize<br />An easy way to roll back a bad release<br />
  18. 18. My plans for automated deployment<br />Copy build artifacts to a production server<br />Extract, re-run unit tests, and install into a stand-by workspace<br />local::lib or separate Xen image<br />Start up server in testing mode<br />Non-live stand-by database<br />Testing URL or port number<br />Run Selenium tests against the server<br />
  19. 19. My plans for automated deployment (cont)<br />Switch server into production mode, but leaving it on a staging address<br />Switch back to using the real production database<br />Run non-invasive smoke tests against the real database<br />
  20. 20. My plans for automated deployment (cont)<br />If all the testing stages are successful, switch the web server configuration (nginx, Apache, load balancer, etc) to direct traffic to the new server<br />Re-run smoke tests against the production URL (optional)<br />Provide an easy mechanism to quickly re-activate the previous server by redirecting traffic back at the old daemon<br />
  21. 21. Rome wasn’t burnt in a day…<br />Wonderful thing is, you don’t need every component to be successful.<br />Can be organically grown as your code matures<br />You can build as much, or as little, as necessary<br />
  22. 22. Learn from your mistakes<br />Failure is wonderful: it teaches you what you need to know<br />When something breaks:<br />Learn what the root cause was<br />Write a failing test to prove the desired behavior isn’t being met<br />Fix the code, and watch your test go green<br />Any future failures in that area should now be caught<br />
  23. 23. To err is human, so get rid of them<br />Humans are messy, problematic, and error-prone<br />Eliminate humans from repetitious tasks, such as<br />Testing<br />Production deployments<br />Rollbacks<br />The more you automate, the less can go wrong unpredictably<br />
  24. 24. Questions?<br />