Continuous integration practices to improve the software quality

Continuous integration practices to improve the software quality

• 1.
  Continuous Integration PRACTICES to improve softwarequality
• 2.
  2 “Our highest priorityis to satisfy the customer through early and continuous delivery of valuable software.” The Agile Manifesto, First Principle
• 3.
  Practices 01
• 4.
  Continuous workflow analysis4 • What can be automated? • Create a big picture of the product lifecycle • Find potential areas which can benefit from automation • Analyze the effort x time x cost ! Code Development Unit Tests Code Analysis Code Review Integration stage Code Merge Integration Testing Packaging Deployment QA Manual Exploratory Test UAT Release Staging Production Release rollback 01
• 5.
  " Self-service 5 •Official builds are not performed on developers’ machines • Self-service builds plus nightly builds • Push-button deployments to all environments • Cross-Functional Teams can use push-buttons • There is no "Build Team”, everyone collaborates • Testing environment state is isolated from others to avoid side-effects Using push-buttons like a boss○ 01
• 6.
  Design pipelines foryour product lines 6 Commit Stage Unit Tests Code Analysis Code Review % Triggers /branches/product-1.0 Development Unit Tests Code Analysis Development pipeline Build Package Sanity Tests Verify Publishing Test Report Unit Test Coverage Project Metrics Artifact Repository Fast Builds pattern & Artifact Repository' 01
• 7.
  7 Setup Environment Infrastructure & Data QAautomation pipeline Deploy Install packages Automated Test Plan Integration, Functional, Regression, Performance, etc. Publishing Test Report Test Coverage Performance Benchmark ○ Push-buttons Scheduled builds Repository changes { % /branches/product-1.0 Triggers Design pipelines for your product lines Self-service " + Nightly-builds { Artifact Repository' 01
• 8.
  8 Setup Environment Infrastructure Data Testing Manual Exploratory ○ Deploy Install packages Health check ○ (QA Team UAT Self-service " deployments Design pipelines for your product lines Deployment pipelines User Acceptance Consumer Preview Demonstrations Beta testing 01
• 9.
  Patterns 02
• 10.
  Patterns and Anti-patterns10 { ) * Anti-pattern Code integrated after days or weeks. Incomplete modifications. Pattern Daily commit, by task commit Anti-pattern Manual code reviews. Learning of code quality issues later in the development cycle. Pattern Fail a build when a project rule is violated: architectural breaches, coding standard violations… Anti-pattern Build relies on “tribal knowledge” or IDE settings. Unable to use CLI. Pattern IDE independent. It relies on CLI. Commit Often Build threshold Independent Build 02
• 11.
  11 Anti-pattern Throwing everything into thecommit stage process: full code analysis, full regression tests… Pattern At the commit stage get the feedback in minutes. First things first, postpone full tests and complex analysis. Anti-pattern Builds stay broken for long periods of time, thus preventing developers from checking out functioning code. Pattern Fix software delivery errors as soon as they occur; stop the line. Anti-pattern Email-only alerts. Pattern Displays the status and QA feedback information. You can also use audio notifications. Fast Builds Stop the Line Visible Dashboards Patterns and Anti-patterns +),- 02
• 12.
  12 Anti-pattern Notifications are notsent; notifications are ignored; CI system spams everyone with information they cannot use. Pattern Send automated feedback from CI system to all Cross-Functional Team members. Anti-pattern Do not use CI feedback to improve operations. Pattern For each iteration, discuss action points to improve the quality and delivery process for the next iteration. Continuous feedback Continuous Improvement Patterns and Anti-patterns . / 02
• 13.
  Agile Integration 03
• 14.
  Agile and ContinuousIntegration 14 • Agile summary • Daily stand-up meetings • Anticipating risks and impediments • Team focuses on sprint delivery 03 SYSTEMATIC QUALITY CONTROL SPRINT REVIEW / RETROSPECTIVE 2-4 Weeks
• 15.
  15 • Objective • Foreach sprint the deliverable must potentially be production-ready • Daily feedback • Build status and reports • Statistics and Trends • Test report • Code violations • Code coverage • Project metrics Agile and Continuous Integration03
• 16.
  16 • Sprint Retrospective •Use CI feedback to continuous improve the process and the product quality • Diagnosing pitfalls and registering sprint action points • Unrelated activities (to the backlog) • Implementing automation tasks • Monitoring the status • Preventive maintenance • Multiple environment management: Build, Testing, UAT… Agile and Continuous Integration03
• 17.
  See more… • Quickstart for Continuous Integration • References: [1] http://refcardz.dzone.com/refcardz/continuous-delivery-patterns [2] http://martinfowler.com/articles/continuousIntegration.html [3] http://guide.agilealliance.org/guide/ci.html 0 fabricioepa.wordpress.com
• 18.
  Contact FABRICIO EPAMINONDAS 1 linkedin.com/in/fabricioepa 0fabricioepa.wordpress.com 2 @fabricioepa MARCELO FREIRE 1 linkedin.com/in/marcelofreire88