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.

Continuous Delivery - Automate & Build Better Software with Travis CI


Published on

First Section:
Continuous Delivery as a software engineering approach.
(This is beneficial for Project Managers, DEVs & QAs.)

1. Projects Case Studies to explain why you should adopt Continuous Delivery.
2. Advantages & Reasons for releasing software more frequently.
3. How to make a Reliable / Production Ready Software.
4. Ingredients of Continues Delivery.
5. Tools/ approaches to choose while using Continues Delivery Methodology.

Second Section:
Technical side of Continuous Delivery.
(This is more beneficial for DEVs/ QAs than Project Managers.)

1. Testing a Software.
2. Measuring Code Quality / Analytic to visualize teams performances.
3. Tools: Code Syntax Checker, Testing Framework, Build Automation, Automated Reporting/ Analytic Dashboard.
4. Continuous Delivery Automation over Cloud using Travis CI - Live demonstration.

Third Section:
1. Sample Projects for audience to adopt right tools for development, testing & deployments.
2. Q&A.
By Waqar Alamgir

Published in: Software
  • Be the first to comment

  • Be the first to like this

Continuous Delivery - Automate & Build Better Software with Travis CI

  1. 1. Continuous Delivery @wajrcs folio3, 26 Jan 2017
  2. 2. Case Studies
  3. 3. Agile 101 & The first sprint of a Team
  4. 4. Iteration Analysis + Design Development Testing + Showcase 0 1 2 3 4 Integration + QA Release and operation Customer Centralized QA IT Operations "Agile" team The "last mile" Agile 101
  5. 5. Barnes&Noble | NOOK
  6. 6. disrupting traditional businesses Flickr, a Yahoo company - Web 2.0
  7. 7. Why Releasing Frequently?
  8. 8. 1. Build the right thing Eric Ries, “The Lean Startup” Customer development Agile product development Releasing Frequently
  9. 9. Do Less “Far More than 50% of functionality in the Software is never or rarely used. Many are no value features.”
  10. 10. • Create hypothesis • Deliver minimum viable product • Get feedback (repeat) Eric Ries, “The Lean Startup” Data Ideas BuildLearn Scientific Method Measure Code
  11. 11. “How long would it take your organization to deploy a change that involved just one single line of code? Do you do this on a repeatable, reliable basis?” Mary and Tom Poppendieck, Implementing Lean Software Development, p59. Ask this Question
  12. 12. 1. build the right thing 2. reduce risk of release John Allspaw: “Ops Metametrics” Releasing Frequently
  13. 13. Optimize for MTRS
  14. 14. Mean Time Between Failures Mean Time Restore Service John Allspaw: “Building Resilience in Web Development and Operations” Optimize for MTRS
  15. 15. 1. build the right thing 2. reduce risk of release 3. real project progress Releasing Frequently
  16. 16. Releasing Frequently
  17. 17. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software Agile Manifesto
  18. 18. Software always be production ready. Releases tied to business needs, not operational constraints. Continuous Delivery
  19. 19. Fast, automated feedback on the production readiness of your applications every time there is a change - to code, infrastructure, or configuration Production-ready Software
  20. 20. automation patterns and practices collaboration Continuous Delivery
  21. 21. configuration management More: continuous integration automated testing Ingredients
  22. 22. Develop Build Mainline Server Build pull Local Workstation Build push ✔ Done!
  23. 23. “Cease dependence on mass inspection to achieve quality. Improve the process and build quality into the product in the first place” W. Edwards Deming Build quality
  24. 24. Business facing Technology facing Critiqueproject Supportprogramming AUTOMATED Functional acceptance tests MANUAL Showcases Usability testing Exploratory testing Unit tests Non-functional Integration tests acceptance tests System tests (performance, scaling, ...) AUTOMATED MANUAL /AUTOMATED Diagram invented by Brian Marick Different Kinds of Testing
  25. 25. an automated implementation of your system’s build, deploy, test, release process visibility feedback control Deployment pipeline
  26. 26. Delivery team Version control Build & unit tests Automated acceptance tests User acceptance tests Release Check in Feedback Trigger Check in Feedback Trigger Trigger Check in Trigger Trigger Approval Approval Feedback Feedback Feedback Feedback Deployment Pipeline
  27. 27. Why? • Easier to test • Easier to measure • Easier to follow • Streamlines the development process Code Quality When someone doesn’t follow the coding style guidelines
  28. 28. • PEAR coding standard - • PEAR2 coding standard - php • PHP Standards Working Group - standards Measuring Code Quality
  29. 29. • Use an indent of 4 spaces, with no tabs. • Control Structures: <?php if ((condition1) || (condition2)) { action1; } elseif ((condition3) && (condition4)) { action2; } else { defaultAction; } ?> PEAR Coding Standard
  30. 30. • Broad • Strict, but flexible • Based on a “standard” standard • Everyone must follow Custom Standards
  31. 31. "tokenises your PHP, JavaScript and CSS files and detects violations of a defined set of coding standards“ • PEAR package • Single file or entire directory • Preset and customizable PHP_CodeSniffer
  32. 32. $ phpcs /myDir/myFile.php FILE: /myDir/myFile.php -------------------------------------------------------------------------------- FOUND 3 ERROR(S) AFFECTING 3 LINE(S) -------------------------------------------------------------------------------- 2 | ERROR | Missing file doc comment 20 | ERROR | PHP keywords must be lowercase; expected "false" but found "FALSE" 47 | ERROR | Line not indented correctly; expected 4 spaces but found 1 -------------------------------------------------------------------------------- Output
  33. 33. • Unit - the smallest piece of testable code within my application or script. • Unit test - a piece of code that executes the unit and then evaluates the result returned. Unit Tests
  34. 34. • Make sure the unit is small enough so the test is testing a single function. • Make sure the test is efficient enough to run repeatedly, perhaps even a thousand times a day. • Make sure the tests do not depend on each other. Each test should be able to run completely separately from other tests. Tips
  35. 35. function validateName($name) { if ((strlen($name) > 1) && (strlen($name) < 50)) { if (ctype_alpha(str_replace(array(" ",",","-","'"),"",$name))) { return true; } else { return false; } } else { return false; } } assert(validateName("Beth's Test Name"));
  36. 36. How Many Tests? Enough to test every basic function of the code.
  37. 37. • Standardize test format • Easily run tests • Analyze results Testing Frameworks
  38. 38. PHPUnit - Pros: • Good documentation • Lots of examples online • Integrates with many other popular tools and platforms Cons: • Command line only
  39. 39. SimpleTest - Pros: • Run on command line or in browser • Can test front-end functionality Cons: • Not as integrated as PHPUnit
  40. 40. Selenium - Pros: • Can test front-end functionality • Selenium-WebDriver (makes direct calls to the browser using each browser’s native support for automation) Cons: • Not a native PHP tool, but bindings are available from several third-parties
  41. 41. • Perform a DB query to update the schema, clear a cache, upload files, run cron tasks, etc. Automate The Build
  42. 42. Phing - • PHP project build system • Based on Apache Ant • XML build files and PHP "task" classes • Integrates with both PHPUnit and SimpleTest as well as phpDocumentor • Platform independent • No required external dependencies
  43. 43. PhingBuildfile: <?xml version="1.0" encoding="UTF-8"?> <project name="FooBar" default="dist"> <!-- ============================================ --> <!-- Target: prepare --> <!-- ============================================ --> <target name="prepare"> <echo msg="Making directory ./build" /> <mkdir dir="./build" /> </target> <!-- ============================================ --> <!-- Target: build --> <!-- ============================================ --> <target name="build" depends="prepare"> <echo msg="Copying ./about.php to ./build directory..." /> <copy file="./about.php" tofile="./build/about.php" /> </target> <!-- ============================================ --> <!-- (DEFAULT) Target: dist --> <!-- ============================================ --> <target name="dist" depends="build"> <echo msg="Creating archive..." /> <tar destfile="./build/build.tar.gz" compression="gzip"> <fileset dir="./build"> <include name="*" /> </fileset> </tar> <echo msg="Files copied and compressed in build directory OK!"/> </target> </project>
  44. 44. Maven - • Supports Ant tasks • Large library of third-party plug-ins to integrate other continuous integration tools • Helps shield you from the details of the build • For Java-based projects, so you’ll need Maven for PHP:
  45. 45. Capistrano - • A remote server automation and deployment tool written in Ruby.
  46. 46. Capistrano File: set :application, "yii_blog" #Edit your app name set :repo_url, "" # EDIT your git repository if ENV['user'] set :repo_url, "https://" + ENV['user'] + "" # EDIT your git repository end set :deploy_to, "/var/www/html/yii-capistrano/" # EDIT folder where files should be deployed to set :scm, "git" set :branch, ENV['branch'] || "master" namespace :deploy do # Writing permissions to /protected/runtime/ and /assets/ desc "Restart" after :updated, :build do on roles(:app) do within release_path do execute :chmod, "-R 777 #{release_path}/protected/runtime/" execute :chmod, "-R 777 #{release_path}/assets/" end end end # Copy yii configuration files /protected/config/ desc "Copy config file" after :updated, :build do on roles(:all) do |host| %w[ yii-config/main.php , yii-config/console.php ].each do |f| upload! "" + f , "#{release_path}/protected/config/" + f end end end # Run yii database migrations desc "Build" after :updated, :build do on roles(:app) do within release_path do execute :php, "#{release_path}/protected/yiic migrate --interactive=0" end end end end
  47. 47. • phpDocumentor 2: • Merging phpDocumentor and DocBlox • Automates documentation • Tutorial: r/HandS/phpDocumentor/tutorial_phpDocument or.howto.pkg.html Documentation
  48. 48. /** * Does something interesting * * @param Place $where Where something interesting takes place * @param integer $repeat How many times something interesting should happen * * @throws Some_Exception_Class If something interesting cannot happen * @author Waqar Alamgir <bonjour@waqaralamgir.t> * @return Status */ /** * Short description for class * * Long description for class (if any)... * * @copyright 2016 Zend Technologies * @license PHP License 7.0 * @version Release: @package_version@ * @link * @since Class available since Release 1.2.0 */
  49. 49. Technical Debt Assigns a technical debt value • The debt • The cost to reimburse • The work to reimburse • The breakdown When the technical debt unrolls
  50. 50. 1. Email plugin Sends a build status email. 2. Lint plugin/ Php parallel lint plugin This plugin runs PHP's built in Lint (syntax / error check) functionality. Similar to the standard PHP Lint plugin, except that it uses the PHP Parallel Lint project to run. 3. Pdepend plugin Runs PDepend software metrics. 4. PHP Code Sniffer plugin Runs PHP Code Sniffer against your build. 5. Php copy paste detector plugin Runs PHP Copy / Paste Detector against your build. 6. PHP Docblock Checker Runs the PHP Docblock Checker against your build. This tool verifies that all classes and methods have docblocks. 7. Php loc plugin Runs PHPLoc against your project and records some key metrics. 8. Php mess detector plugin Runs PHP Mess Detector against your build. Records some key metrics, and also reports errors and warnings. 9. PhpUnit Plugin Runs PHPUnit tests against your build. 10. Technical Debt Plugin Checks all files in your project for TODOs and other technical debt.
  51. 51. • Cruise Control • Hudson / Jenkins • PHP CI • Travis CI Continuous Integration Tools
  52. 52. PHPCI - Reporting
  53. 53. • Project is small, budget is small… • Evaluate which tools are worthwhile to your specific project. Yes, But…
  54. 54. • Consider including unit tests or code cost/coverage reports in your deliverables to your customers as an added value to them (and you down the road). Make It a Deliverable
  55. 55. Project: A customer hires you to create a registration form for a one-time event. It’s a small customer with a small budget. It should take a couple hundred lines of code in a single file, results will be e-mailed. It will be tested by the event staff and the marketing department on the live site as they do not have a test environment, and it will only be live for two months.
  56. 56. What they need: 1. If they do not have an in-house standard for you to follow, write it using one of the main coding standards, like PEAR. 2. Create unit tests for it. What they don’t need: 1. In-depth reporting 2. Full automation, including build. 3. Documentation
  57. 57. Project: A customer hires you for an ongoing project. On the 15th of every month, they need you to go in and add a new survey to collect data and write it to a database. The previous month’s survey data needs to be backed up and cleared out of the database when the new survey goes live.
  58. 58. What they need: 1. If they do not have an in-house standard for you to follow, write it using one of the main coding standards, like PEAR. 2. Create unit tests for it and use a testing framework. 3. Automate the build. What they don’t need: 1. In-depth reporting (Maybe) 2. Documentation (Maybe)
  59. 59. Project: A customer hires you to write one part of a very large application. Other consultants that you do not have access to will be working on other parts of the application at the same time.
  60. 60. What they need: 1. All of it In this situation, see if you can convince them to get everyone working on a unified continuous integration platform utilizing a complete suite of continuous integration tools from standards to documentation and fully automated everywhere in between.
  61. 61. Not everything is beneficial enough to use in every situation, so choose the right tools for your project and needs. Take Away #1
  62. 62. The fewer steps I have to remember to do manually, the more successful my project will be. Take Away #2
  63. 63. release ! = deployment No builds. No change. No upgrades. Is it read-only Day? NAH! NOT NECESSARILY Take Away #3
  64. 64. [featureToggles] wobblyFoobars: true flightyForkHandles: false Config File <?if ($wobblyFoobars) {?> ... various UI elements <?}?> some.php $fork_handle = ($featureConfig->isOn(‘flightlyForkHandles‘)) ? new flightyForkHander(aCandle) : new forkHandler(aCandle); other.php Stolen from Martin Fowler Feature Toggles
  65. 65. Travis Demo
  66. 66. Resources • CruiseControl - • Guide to writing your own PHP_CodeSniffer standards (Official) - • Guide to writing your own PHP_CodeSniffer standards (Alternate) - custom-coding-standards-php-codesniffer • Hudson - • Jenkins - • Maven - • PEAR coding standard - • PEAR Package Manager Installation - • PEAR Packages Installation - • PEAR2 coding standard - • Phing - • PHP Standards Working Group - • PHP_CodeSniffer - • phpDocumentor 2 - • PHPUnit - • phpUnderControl - • Selenium - • SimpleTest - • Sonar - • Sonar PHP Plug-in - • Sonar Technical Debt Plugin - • Template for Jenkins Jobs for PHP Projects by Sebastian Bergmann -
  67. 67. QA Please send your Feedback at @wajrcs / Thank Y u