Accelerate Chapter 4 Discussion Points

Moving on to chapter 4 of Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, we begin to cover technical practices:

• Many Agile adoptions have treated technical practices as secondary compared to the management and team practice, but research shows that technical practices play a vital role
• Continuous delivery practices have a measurable impact on software delivery performance, organizational culture, and other outcome measures
• What is continuous delivery?
• A set of capabilities that enable us to get changes to production safely, quickly and sustainably
• Five key principles of continuous delivery:
• Build quality in
• We invest in building a culture supported by tools and people where we can detect issues quickly, so that they can be fixed straight away when they are cheap to detect and resolve
• Work in small batches
• By splitting work up into much smaller chunks that deliver measurable business outcomes quickly, we get essential feedback so that we can course correct
• Computers perform repetitive tasks; people solve problems
• Reduce cost of pushing out changes by taking repetitive work that takes a long time (regression testing, software deployments, etc.) and invest in simplifying and automating this work
• Thus we free up people for higher-value problem-solving work
• Relentlessly pursue continuous improvement
• High performing teams are never satisfied: they always strive to get better
• Make the state of system-level outcomes transparent
• System-level outcomes can only be achieved by close collaboration between everyone involved in the software delivery process
• In order to implement continuous delivery, we must create the following foundations:
• Comprehensive configuration management
• It should be possible to provision our environments, build, test, and deploy in a fully automated fashion purely from version control info
• Continuous integration
• Following principles of small batches and building quality in, high-performing teams keep branches short-lived (less than one day's work) and integrate them into trunk/master frequently
• Continuous testing
• Because testing is so essential, we should be doing it all the time as an integral part of the development process
• Automated unit and acceptance tests should be run against every commit
• Developers should be able to run all automated tests locally in order to triage and fix defects
• Testers should be performing exploratory testing continuously against the latest builds to come out of CI
• No one should be saying they are "done" with any work until all relevant automated tests have been written and are passing
• The impact of continuous delivery
• Strong impact on software delivery performance
• Helps to decrease deployment pain and team burnout
• Teams identify more strongly with the organization they work for
• Improves culture
• Lower change fail rates
• Drivers of continuous delivery
• Version control
• Deployment automation
• Continuous integration
• Trunk-based development
• Test automation
• Test data management
• Shift left on security
• Loosely coupled architecture
• Empowered teams
• Monitoring
• Proactive notification
• The impact of continuous delivery on quality
• Less time spent on rework or unplanned work
• Unplanned work: different between "paying attention to the low fuel warning light on an automobile versus running out of gas on the highway"
• Continuous delivery practices: What works and what doesn't
• Nine key capabilities that drive continuous delivery
• Version control
• What was most interesting was that keeping system and application configuration in version control was more highly correlated with software delivery performance than keeping application code in version control
• Configuration is normally considered a secondary concern to application code in configuration management, but our research shows that this is a misconception
• Test automation
• The following practices predict IT performance:
• Having automated tests that are reliable
• Developers primarily create and maintain acceptance tests, and they can easily reproduce and fix them on their development workstations
• None of this means getting rid of testers
• Testers perform exploratory, usability, and acceptance testing, and help to create and evolve suites of automated tests by working with developers
• Test data management
• Successful teams had adequate test data to run their fully automated test suites and could acquire test data for running automated tests on demand
• Test data was not a limit on the automated tests they could run
• Trunk-based development
• Developing off trunk/master rather than long-lived feature branches was correlated with higher delivery performance
• Teams that did well:
• Had fewer than three active branches at any time
• Their branches had very short lifetimes (less than a day)
• Never had "code freeze" or stabilization periods
• These results are independent of team size, organization size, or industry
• We hypothesize that having multiple long-lived branches discourages both refactoring and intrateam communication
• Note that open source projects whose contributors are not working on a project full time works differently
• Information security
• On high performing teams, the infosec personnel provided feedback at every step of the software delivery lifecycle, from design through demos to helping with test automation
• Adopting continuous delivery
• Continous delivery improves both delivery performance and quality, and also helps improve culture and reduce burnout and deployment pain
• (Here it lists six, and earlier it listed eleven; So what are the nine?)