cost for cloud provider ▪ GitHub acquisition ▪ Services being abandoned (Stride from atlassian) ▪ EU data shield ▪ Migration from datacenter ▪ Move to using common source control ▪ Move to cloud deployment with already familiar tool Slide 5
More than one developer working on project need to share same code base ▪ Solution ▪ Source control offers elegant solution for collaboration ▪ Widely adopted ▪ Implementation ▪ Gerrit implements free and open source git source code repository ▪ Clients available and integrated in IDE’s and CLI ▪ Quality assurance ▪ Easy refactoring ▪ History containing information about changes and authors ▪ Teaching opportunity Slide 9
use source control ▪ Rule of thumb: Always ▪ There is no project small enough that it should not be put into source control ▪ Even POC or hello world projects can be valuable for someone ▪ Early implementation problems get documented in history ▪ Warning ▪ Source control tools usually offer statistics about user activities, don’t use them to measure your developer productivity • They will just do more commits to improve their statistics • It will not give you any information about quality of work ▪ Guidelines ▪ It is very important to have common non IDE dependant code formatting • i.e. Google code formatter ▪ Commit messages are important Slide 10
has great impact on code quality ▪ Code review is trying to mimic pair programming without overhead ▪ Code Quality impact ▪ More experienced programmers can review code to maintain quality standards ▪ All code gets second view with different perspective ▪ Gerrit ▪ Implementation of code review as pull requests ▪ Allows integration with other tools to do automated approval ▪ Very advanced CLI support ▪ New and shiny polymer UI in version 2.16 Slide 13
Pull requests as small as possible ▪ Avoid starvation of junger developers ▪ Be flexible (for skeleton teams approvals can be big overhead) to avoid • blocking developers by waiting for approval • overwhelming senior developers with too much requests Slide 14
Deployments are Error prone and builds are not repeatable ▪ Information about environment status can be lost ▪ Knowledge exchange about build and deployment processes ▪ Level of automation ▪ Automate as much as possible ▪ All non automated things will come back later as technical dept • As lost knowledge due to people change • As time consuming items when scaling up ▪ Naming conventions are most important consideration (Prefix all the stuff) ▪ Jenkins ▪ Generic extendable build and delivery automation tool ▪ Trunk based development and delivery pipelines are first class citizens Slide 17
Use build automation tools (Maven, Gradle) on all projects from start ▪ Use CI/CD tools as soon as possible on any project ▪ Deploy small batches to production ▪ Don't tightly couple projects, independent life cycles bring more value • Integration tests are easier to maintain and write • Deployment process is simpler Slide 18
▪ Wasted time on pull requests for common code issues (i.e. formatting) ▪ Measure quality of code and give measurable code quality targets ▪ Danger zone ▪ Eliyahu M. Goldratt: Tell me how you measure me, and I will tell you how I will behave ▪ Most important goal is to avoid developers doing things just to improve metrics (Code coverage most likely candidate) ▪ SonarQube ▪ Implements automated solution for code quality analyzes ▪ Automatically checks for 400+ common code quality issues and smells Slide 22
▪ Use code review to protect coding standards and teach new developers ▪ Automate build and deployment ▪ Write tests to make refactoring safe ▪ Split monolith into microservices ▪ Reduce deployment cycle • Ideally each microservice independant release cycle with each commit being deployed to production before next merge is done ▪ Measure quality using metrics tool Slide 26
specific cloud provider should be carefully considered with exit cost in mind ▪ Every project must have ▪ Code repository ▪ Build automation and dependency management ▪ Every project should have ▪ Code review ▪ Delivery pipeline ▪ Code quality analysis Slide 28