Continuous Integration in Agile Teams

Presentation slides at For Loop Meetup (November 5, 2016)

Transcript

1. Continuous Integration in Agile Teams Best Practices Oyewale Oyediran Software Engineer, @ShopKonga
2. What is CI really about? • It is really about creating a clean build of the system as frequently as changes are created. • Keeping the code base as healthy as possible. • And ensuring that every iteration of the system correct and complete. Can be deployed at anytime.
3. Continuous Integration is a key part of Agile teams • Kick-ass agile teams (usually cross-functional, Engineers, Product managers and any other members of your team) require a harness to help them row in the same direction while working optimally. • Lets individuals focus on their tasks while helping to keep the integrity of the whole system. • This is fundamental to true agility.
4. Source Control Well, It’s 2016. I think nearly everyone uses some form of version control to manage their code base.
5. Source Control Regular commits • Checking in code frequently reduces the chances of having merge conflicts. • Conflicts interrupts a team’s flow. One has to determine which change is the correct one by consulting with others
6. Source Control Branching Strategy Source: http://nvie.com/posts/a-successful-git-branching-model/ As with everything agile, find what works for your team and keep improving. Feature-Branches Dev Master
7. Build Tools A single command should be able to build the system.
8. Build Tasks 1. Download Dependencies The build process should involve downloading the project dependencies. composer; pip, npm etc.
9. Build Tasks 2. Compile Compile your code (of course for compiled language)
10. Build Tasks 3. Run Tests • Run your Unit/Regression (and any other automated)Tests. • If any test is failing, stop the build.
11. Build Tasks 4. Measure Code Quality Agile teams care very much about their code quality. So we measure and ensure the quality is above an accepted threshold. • Code Coverage • Coding Standard (PSR2, PEP-8 etc) • Linting Some other metrics • Copy Paste Detector • Cyclomatic Complexity Changes that does not meet your team’s quality thresholds should be halted.
12. Build Tasks 5. Package the build artifact • Package the build; Generate your jars, wars, zip, deb. (git tagging). • Important to also generate the code quality information for viewing; HTML, Graphs etc.
13. Build Tasks A typical build file http://jenkins-php.org/automation.html Too large to insert here.
14. Build Server • A centralized stable and reliable environment for building software. • Could consist of multiple machine nodes (one master, and zero or more slaves) • Every build starts with a clean state. • Expected to create a similar environment as your final deployment environment; Operating Systems, application configurations etc.
15. Build Server Benefits • Alerts the team (and author) of failing builds. (Slack, Email) • Makes every build information (quality, test results etc) available • Makes it easy for team members to get the latest builds (artifacts) (while keeping old builds too)
16. Staging Environment • Have a test environment matching your production systems as much as possible. • Successful Builds (dev and/or feature branches) gets deployed here. • Manual Tests happens on here.
17. References • https://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software • https://www.atlassian.com/agile/continuous-integration • http://nvie.com/posts/a-successful-git-branching-model/ • http://jenkins-php.org/automation.html • https://en.wikipedia.org/wiki/Continuous_integration
18. Thank You As with everything agile, it’s important to find what works best for your team and progressively improve. That is true agility. @waleoyediran