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.
1 of 24

Automating Perl deployments with Hudson

10

Share

Download to read offline

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

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

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 />

×