a brief introduction to creating quality software continuously Copyright 2011 Davisbase, LLC

Size: px

Start display at page:

Barbara Nash
5 years ago
Views:

1 a brief introduction to creating quality software continuously

org (704) 835-0194 Interests: Cloud Computing, Agile Development & Team

2 Andy Painter Agile Coach/Trainer/Consultant CSM, CSP, CSD Instructor (704) Interests: Cloud Computing, Agile Development & Team Practices, Web Scaling Computing & Web Application Development, Emerging Dynamic Languages & Frameworks

3 Continuous Integration Attitude Contrary to popular belief, continuous integration is an attitude, not a tool. It's a shared agreement by the team that: When we get the latest code from the repository, it will always build successfully and pass all tests. We will check in our code every two to four hours. --- James Shore, The Art of Agile

4 Continuous Integration Practices Maintain a code repository Automate the build Make the build self-testing Everyone commits every day Every commit (to mainline) should be built Keep the build fast Test in a clone of the production environment Make it easy to get the latest deliverables Everyone can see the results of the latest build Automate deployment Practices specified by Martin Fowler,

5 Continuous Integration Defined A process that supports teams in making small, working incremental changes to software. Continuous Integration is an automated process that provides feedback and supports: Transparency Consistency Continuous Builds Continuous Inspections Continuous Testing Continuous Deployment

6 Automate, Automate, Automate Understand how you work individually and collectively Automate anything you do more than once (e.g. task, test, process) Automation is essential to shorten feedback loops and maintain flow state

7 Automate Early & Often Steep drop off in benefits of Automation Get the benefits when you need it most Cost will prohibit adoption later as benefits are not easy seen Source: Succeeding with Agile: Software Development using Scrum, Mike Cohn

8 CI Basic Tenets Developer Discipline Version Control Automated Build Integration Build CI Server Feedback

9 Typical Development Large grained commits or Version control as a backup Independent development IDE driven manual builds

10 Developer Discipline Developer checks out a working version of the code Makes modifications & runs local build Checks for any updates If build was successful, checks in modifications Moves on to next task

11 One Build Script clean Build Script compile setup test deploy doc

12 Build Scripting Tools Ant NAnt MSBuild GAnt Rake Maven

13 Scripted Build Scripted Build

Feedback Failures should be visible and transparent Methods Email Text

14 Feedback Failures should be visible and transparent Methods Text Message (SMS) Sounds, X10 Ambient Orb RSS feeds Failures should be handle IMMEDIATELY

15 Version Control All software assets must be version controlled in a single, centralized, and accessible place code tests database scripts dependencies tools configuration documentation

16 Integration Build Reduces Assumptions Stable Configuration Easily Compare Results

17 Integrated Build Scripted Build Integration Build Integration Build

18 CI Server Supports multiple build types (now, scheduled, polling, event) Supports multiple version control systems (CVS, SVN, Git, and many more) Supports a variety of build scripting tools (Rake, Ant, NAnt,... ) Notifications History and trending SW & Results are accessible & transparent

19 CI Server Role in CI Process CI Server is listening for changes to the project in version control If any changes are detected, the CI Process begins CI Server checks out the code from version control Builds the software If build fails, CI Server notifies team CI Server publishes the build results CI Server resumes listening for changes to the project

20 Continuous Builds Scripted Build Integration Build CI Transparency & Continuous Builds Integration Build Server

21 Continuous Inspections Scripted Build Integration Build CI Integration Build Transparency & Continuous Builds Continuous Inspections Server

22 Building a Strong Base Small in number Tools: Selenium, Watir, QTP At least one per Story Tools: FIT/Fitnesse, BDD At least one per class or module Tools: JUnit, xunit

23 Automated Unit Testing Scripted Build Integration Build CI Integration Build Transparency & Continuous Builds Continuous Inspections Automated Unit Testing Server

24 Automated Acceptance Testing Scripted Build Integration Build CI Integration Build Transparency & Continuous Builds Continuous Inspections Automated Unit Testing Server Automated Acceptance Testing

25 Automated Deployment Scripted Build Integration Build CI Integration Build Transparency & Continuous Builds Continuous Inspections Automated Unit Testing Server Automated Acceptance Testing Automated Deployment

26 Functional Testing Scripted Build Integration Build CI Integration Build Transparency & Continuous Builds Continuous Inspections Automated Unit Testing Server Automated Acceptance Testing Automated Deployment Automated Functional Testing

27 Multi-Phase Continuous Integration CI CI Integration Build Integration Build Server Server CI Manual & Exploratory Testing Integration Build Server

28 Through the Eye of Testing Manual & Exploratory Testing CI Integration Build GUI Tests Server CI Acceptance Tests Unit Tests Integration Build Server CI Unit Tests Integration Build Server

29 Anti-Patterns of Success Manual deployments Manual configuration Deploying to a test or stage environments after development is complete Check-in without local build and test Check-in to failed build Check-out from failed build

30 CI Roadmap & Strategy Start a Roadmap for your CI/automation stack by reviewing and evaluating tools for unit testing, integrated testing, acceptance testing, functional testing and static analysis. Introduce one new tool every few Iterations Discuss and review effectiveness of tools Remove any tools that are creating waste or not adding value

31 Your Questions, My Answers For those questions we do not have time to answer during the webinar, I will be providing a written response.

32 How to Claim Your PDU Go to ccrs.pmi.org/ Search for ASPE as a Registered Education Provider. Our number is 2161 At the bottom of our details page, select See Provider s Activities Find the activity code stated by the moderator during the presentation: WS The seminars are Category A for one PDU

Test Driven Development

Test Driven Development driving the development of quality software through tests presented by Introduction and Agenda Andy Painter, Davisbase Consulting 15+ years in software development. 5+ years working