Continuous Integration and development environment approach


Published on

Published in: Technology
  • Be the first to comment

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

No notes for slide

Continuous Integration and development environment approach

  1. 1. Continuous Integration and Engineering Environment approach<br />Aleksandr Tsertkov<br />
  2. 2. Continuous integration<br />Continuous Integration provides quick feedback on recent code changes<br />
  3. 3. Continuous Integration<br />Software engineering practice, where project is build frequently<br />Emerged in the Extreme Programming (XP) community<br />
  4. 4. Continuous Integration<br />Build is made by automated build tools like: make, Ant, Maven, etc.<br />Automated tests results and software metrics are collected for each build<br />Build process is executed and results published on CI server<br />
  5. 5. Build<br />CI server executes build scripts regularly:<br />Predefined delay is used to execute build scripts. Every one hour for example<br />CI server regularly checks SCM system and in case of changes made since last build time a new build is made<br />
  6. 6. Build status<br />Each build has a status: successful or failed<br />Build is considered as successful if all build tasks were executed without errors and failed otherwise<br />Automated tests are executed as build tasks<br />
  7. 7. Build status<br />Build status may be reported by email, IM, SMS, etc.<br />
  8. 8. Build artifacts<br />Each build receives unique number. Build artifacts are published with this number.<br />
  9. 9. Build artifacts<br />Build artifacts are different from project to project but usually they include:<br />Binaries: installation package, application files, …<br />Generated documentation: API, end-user documentation, …<br />Unit test results: time taken, code coverage, …<br />Software metrics: LOC changes, PMD, CRAP index, coding standards violations, …<br />
  10. 10. Binary packages<br />Binary packages produced by build process may include:<br />Installation packages<br />Executable binaries<br />Etc.<br />
  11. 11. Documentation<br />Usually API documentation is compiled during build and is published within other artifacts<br />End-user documentation also may be compiled and published accordingly to project needs<br />
  12. 12. API Documentation<br />
  13. 13. Code coverage<br />Code coverage used to show which lines of source code has been tested with unit tests<br />100% code coverage is a required but not a sufficient criteria for measuring test quality<br />
  14. 14. Code coverage<br />
  15. 15. Code coverage<br />
  16. 16. Coding standards violations<br />Strict coding standards in a project help to improve reading and understanding of code and raise maintainability<br />With help of specialized tools coding standards may be checked as part of build process<br />
  17. 17. Software metrics<br />A software metric is a measure of some property of a piece of software or its specifications.<br />LOC - Lines Of Code<br />PMD – Project Mess Detector<br />C.R.A.P. – Change Risk Analysis and Predictions<br />Code coverage<br />
  18. 18. Advantages<br />Early notification about integration errors<br />Early warning about broken code<br />Immediate unit testing of all changes<br />Constant availability of build packages including: testing, demo, beta, etc.<br />Collected software metrics focus developers on producing high quality code<br />
  19. 19. Software<br />A wide range of CI software is available providing different notification medias, SCM systems, build tools support and IDE integration:<br />CruiseControl<br />Bamboo<br />Hudson<br />BuildBot<br />Etc.<br />
  20. 20. CruiseControl<br />CruiseControl is an extensible framework for creating continuous build process:<br />It includes dozens of plugins for a variety of source controls, build technologies, and notifications schemes including email and instant messaging<br />A web interface to view details and access artifacts of builds<br />
  21. 21. CruiseControl<br />CruiseControl is written in Java but is used on a wide variety of projects thanks to different build tools supported:<br />Ant, NAnt, Maven, Phing, Rake, Xcode<br />“exec” builder which can be used with any command-line tool or script<br />
  22. 22. CruiseControl<br />May be used with C/C++ since build tasks can be wrapped into Ant tasks<br />CppUnit or CxxTest can be used as unit testing framework<br />
  23. 23. Generic Visual C++.NET Ant target<br />
  24. 24. CruiseControl<br />
  25. 25. phpUnderControl<br />phpUnderControl is customization of CruiseControl that brings functionality needed for PHP projects:<br />PHPUnit<br />PHPDocumentor<br />PHP_CodeSniffer<br />…<br />
  26. 26. phpUnderControl<br />
  27. 27. phpUnderControl<br />
  28. 28. phpUnderControl<br />
  29. 29. phpUnderControl<br />
  30. 30. phpUnderControl<br />
  31. 31. peer code review<br />Improves code quality and aids software developers professional growth<br />
  32. 32. Code review<br />Code review is a process of checking programming code for common mistakes, vulnerabilities, bugs and errors.<br />Code might be reviewed by author, team members or 3rd party company providing code review service.<br />
  33. 33. Code review<br />Several common types of code review:<br />Formal inspection – code is reviewed on a projector by a team of reviewers<br />Over-the-shoulder review where author walks the reviewer though a set of code changes<br />E-mail pass-around – whole files or changes are packed up by the author and sent to reviewers via email<br />Tool assisted – specialized code review tools are used<br />
  34. 34. Peer code review<br />Systematic examination of code individually by each reviewer.<br />Usually developers are able to review each other code in a small team, but it’s better to set rules for handling review process roles.<br />
  35. 35. Peer code review best practices<br />Review fewer than 200-400 lines of code at a time<br />Take enough time for a proper, slow review, but not more than 60-90 minutes<br />Verify that defects are actually fixed<br />
  36. 36. Advantages<br />Helps to identify bugs early<br />Encourages collaboration and builds a team<br />Helps in keeping code maintainable<br />Improves code quality<br />Improves cross team know-how<br />Shares experience within a team<br />Improves developers professional skills<br />
  37. 37. Peer code review software<br />Reviewboard<br />Crucible<br />CodeCollaborator<br />
  38. 38. Reviewboard<br />
  39. 39. CodeCollaborator<br />
  40. 40. Crucible<br />Web based peer code review tool<br />Simplified workflow<br />Integrates with Fisheye and JIRA since it is ATLASSIAN’s product<br />Pre and post commit reviews are supported<br />Integration into Eclipse & IntelliJ IDEA<br />
  41. 41. Crucible<br />To start a new review Crucible allows:<br />Selecting concrete revision, for example the most recent commit in Subversion or revision identified by number or date<br />Selecting individual files and folders (even from different revisions)<br />
  42. 42. Crucible<br />Supports email notification of:<br />Review requests<br />Review comments<br />Review actions (close, etc.)<br />
  43. 43. Crucible<br />
  44. 44. Crucible<br />
  45. 45. Engineering environment<br />
  46. 46. Engineering environment<br />Our engineering environment approach was specially designed for web development though some subsystems may be utilized for non-web development as well.<br />Environment is based on dedicated server where project code is developed and tested – remote environment.<br />
  47. 47. Environment components<br />CI: CruiseControl + phpUnderControl<br />Peer code review: Crucible<br />SCM system: Subversion<br />Development web servers<br />Database, memcached, etc.<br />Development toolsPhpMyAdmin, PHPUnit, PHPDocumentor<br />
  48. 48. Environment components<br />Each component is highly tuned to simplify it’s use and speed up development<br />Subversion hooks are used to apply validation rules on committed code and send on-commit notifications to the team<br />Web server components are configured accordingly to project requirements<br />
  49. 49. Remote environment<br />Code is developed, tested and stored on a remote dedicated server<br />Each developer has isolated environment where he has good control over his vhosts configuration<br />
  50. 50. Key points<br />Environment similar to production (server OS, cron jobs, tools and software)<br />Abstracts developers from occasional need in environment reconfiguration since this is made only once by server admin<br />Possibility to send links to development/current/demonstration version of project<br />
  51. 51. Key points<br />Build automation, continuous integration<br />Engineering tools suite: debugging tools, common frameworks and libraries, unit testing suite, build tools, database management tools<br />Centralized backup<br />
  52. 52. Subversion<br />Subversion is used as Version Control System and provides following benefits:<br />IDE integration<br />Access over WebDav (web browser)<br />Hooks system<br />
  53. 53. Subversion over WebDav<br />
  54. 54. Subversion Hooks<br />Subversion hooks system allows to execute custom program on some repository event.<br />With post-commit hooks we send on-commit emails notifying team about changed made in the repository.<br />Pre-commit hooks are used to validate coding standards and apply other rules.<br />
  55. 55. Subversion on-commit email<br />
  56. 56. Subversion pre-commit script<br />
  57. 57. Remote development<br />Every developer has a separate account on development server with access over SSH<br />Remote files might be accessed via:<br />SFTP/SCP<br />FTP/FTPS<br />Samba (Windows network share)<br />
  58. 58. Samba share mounted<br />
  59. 59. Private namespace (subdomains)<br />Every developer has full control over subdomains of<br />Subfolders in ~/vhosts/are automatically mapped to domain names:<br />
  60. 60. Development web servers<br />Several development web servers with different configurations and- or modules may run on dev server.<br />With help of reverse proxy it is possible to switch between servers by simply prefixing domain name with server identificator.<br />
  61. 61. Development web servers<br />
  62. 62. Development web servers<br />Three web servers are running on one machine with different versions of PHP installed<br />
  63. 63. Questions?<br />
  64. 64. Thank You!<br />