Introducing Continuous Integration Using Vsts


Published on

A presentation I gave about Continuous Integration and it's role in the software development life cycle with some of my real life experiences.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Introducing Continuous Integration Using Vsts

  1. 1. Introducing Continuous Integration using VSTS<br />Presented By:<br />Mohamed Samy<br />Technical Architect/MVP/Geek<br />
  2. 2. What lifecycle phase do you hate the most?<br /> Gathering requirements? Analyzing requirements? High level design? Detailed Design? Development? Testing? <br />What lifecycle phase requires the most rework and most experienced developers?<br />My sad story, every developers story.<br />Problem Definition<br />
  3. 3. The Cost of bugs<br />
  4. 4. Who’s code is responsible for the problem?<br />It was working great on my machine!<br />The problem is not with our code, the mainframe/server is very slow.<br />Integration nightmares<br />
  5. 5. Put the best developers on the job?<br />Estimate with a lot of buffering for this phase and pray?<br />Leave integration till the end?<br />What was done about it?<br />
  6. 6. Working on someone else’s code. Who likes to do that?<br />Fixing old projects? Upgrading existing code?<br />Adding new features?<br />Project nightmares<br />
  7. 7. Get your hands dirty and start debugging.<br />Read the old design docs.<br />Attend handover sessions.<br />Download the code, build and pray.<br />What was done about them?<br />
  8. 8. A solution for integration issues.<br />Makes getting into a new project easier.<br />Increases the quality of the software.<br />Reduces development time?<br />Introducing CI<br />
  9. 9. Unit test<br />Testing the smallest part of the code (the method)<br />TDD<br />Self testing code, code that tests code<br />Common terms<br />
  10. 10. “Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage. “<br />Martin Fowler- Thoughtworks.<br />CI definitions<br />
  11. 11. Continuous integration describes a set of software engineering practices that speed up the delivery of software by decreasing integration times.<br />CI definitions 2<br />
  12. 12. We need to spread the pain across the whole development cycle and maybe even from the beginning of the design.<br />More frequent small pain instead of one big concentrated jolt of lightning at the end <br />As a developer, life is pain, get used to it!!!!<br />My CI definition<br />
  13. 13. Maintain a single source control repository <br />Automate the build<br />Make your build self testing<br />Everyone commits every day<br />Every Commit Should Build the Mainline on an Integration Machine<br />Keep the Build Fast<br />Test in a Clone of the Production Environment<br />CI practices<br />
  14. 14. The seven commandments<br />
  15. 15. Compilation<br />Test Execution<br />Database integration<br />Code inspection<br />Automated deployment<br />Documentation generation<br />The 6 ingredients of a build<br />
  16. 16. Do you need to develop an enterprise solution that integrates with other applications?<br />Is part of your solution running on other platforms? (web services, RPCs, remoting, Com, CORBA)<br /> Is it a big project with multiple components across multiple teams?<br />Are you afraid of the integration phase?<br />How do I know I need CI?<br />
  17. 17. ICL 1.0- Next to none<br />ICL 1.5- Test on 2 DBs<br />ICL 2.0- Automated regression<br />My Story<br />
  18. 18. Are you crazy? You want the developers to write more code?<br />We need to ship fast, this will slow us down!<br />We can do integration testing at the end of the project.<br />How can I convince the PM?<br />
  19. 19. We always design on the go!<br />Design always evolves even on the waterfall model!<br />Things change midway through the project no matter what your methodology.<br />The industry’s best kept secret<br />
  20. 20. You catch build breaks early on. <br />Helps developers communicate frequently about the build. <br />less regression <br />The feedback loop is smaller. <br />Integration testing moves up in the chain. <br />Every check-in goes through the integration testing where problems are caught early. <br />Continuous integration enforces better development processes. <br />Each developer is held accountable. <br />You always have a latest-and-greatest build to use in demos, showcases, etc.<br />Advantages of CI<br />
  21. 21. Maintenance overhead often increases. <br />Some teams find that the level of discipline required for continuous integration causes bottlenecks. This often requires a shift in the developer mindset. <br />The immediate impact of a check-in often causes a backup because programmers cannot check in partially completed code. <br />Disadvantages of CI?<br />
  22. 22. Performance testing<br />Human interaction with UI e.g. usability testing<br />Load testing<br />What CI doesn’t do<br />
  23. 23. CI Process in TFS<br />
  24. 24. Demo<br />
  25. 25.<br /><br /><br /><br /><br />VSTS Fans - facebook<br />references<br />