Over the years, I’ve shared my knowledge with my clients and colleagues about what Good Software Delivery looks like.
There’s a lot of great publicly available information out there for teams that are trying to improve their software delivery, increase quality, and ship to production with more confidence, but where do you start?
In this blog, I’ll share 6 of my greatest resources, with a little added context before you jump into each topic yourself — but first, here’s an XKCD comic.
- Good Software Delivery
Good Software Delivery spans Developer Effectiveness, DevOps as a culture, Product thinking, Extreme Programming, Continuous Integration, and Continuous Delivery. It helps set the tone for high-performing teams and focuses on short feedback loops, built-in quality, and software engineering (not just doing standups and 2-week sprints and then hoping for the best because that’s what everyone else is doing).
Through a series of blog posts, I’ve shared my philosophy and included demo code that shows the principles in practice. drewkhoury.com/categories/gsd
- Application Architecture
Sometimes teams are in such a rush to “get to the cloud” or “build the next feature” that they forget about their actual application. How you architect your application has flow-on effects that last well beyond the time it takes to make these key decisions.
A great starting point is 12 Factor Apps. 12factor.net
These simple rules have existed for a long time but apply just as well today. They can be great for any team wanting to ensure they have a basic application checklist and are often precursors for future automation or scale. They can also take a lot of effort to achieve, particularly if you’re dealing with a legacy application or tech debt, but I never said it would be easy! Don’t try and fix everything at once, continuous improvement is a wonderful thing.
- Trunk-based development
Wars have been started over branching strategies.
The author of Gitflow (one of the most popular branching strategies in the last decade, especially in enterprise) has recommended that teams consider other strategies with less long-lived branches.
Trunk-based development is a great strategy for teams that have already automated their SDLC and have CI/CD — ie without manual intervention needed to build, test and deploy. It’s also a great target state in many cases, even if your pipeline isn’t fully automated today.
Regardless of your chosen branching strategy, the principles around CI/CD are great for all software delivery teams. trunkbaseddevelopment.com
- CI trunkbaseddevelopment.com/continuous-integr..
Test, test, then test some more
Some teams think of testing as “what you do after coding” or “someone else's problem”. What I teach when working with teams, is that testing should be part of software delivery, not an afterthought. Successful software teams practice quality engineering by embedding testing in everything they do.
The Testing Pyramid is a great starting point, and the following guide shows how to use the Testing Pyramid to Fail Fast and Reduce Risk. contino.io/insights/the-testing-pyramid
Test Driven Development is a practice popular among high-performing teams that need to ship quality code to production often. contino.io/insights/test-driven-development
Testing APIs is often done via Contract Testing, a great example of fast-feedback. contino.io/insights/testing-strategy-APIs
When I talk about Agile Software Development, I always include Extreme Programming (XP) — which touches on TDD, Refactoring, Continuous Integration, Pair Programming, Sustainable Pace, and Collective Ownership. contino.io/insights/agile-software-developm..
- Drew, I want more; what else is there?
Let’s have a look at a client example — We used System Thinking, standardizing processes for build/test/deploy, consistent environment standup, and configuration for local and CI/CD pipelines, Behavior Driven Development (BDD) using Gherkin/Cucumber was also introduced and established as a standard for the organization. contino.io/case-studies/bell-media-test-aut..
20 DevSecOps Best Practices Across People, Process, and Technology (with a focus on security). contino.io/insights/devsecops-best-practices
And when all else fails, there’s Google DevOps/DORA (State of DevOps & Industry Standard Metrics). cloud.google.com/devops
Explore the technical, process, measurement, and cultural capabilities which drive higher software delivery and organizational performance. devops-research.com/research.html#capabilit.. — Version control — CI — Deployment automation — Trunk-based development — Continuous testing — Continuous delivery — Test data management — Code maintainability
- Feedback loops
I touched on feedback loops briefly. They’ll show up in Value Stream Mapping, Developer Experience, and when we look at pairing/PRs, pipelines, and local development.
The longer you leave feedback, the most costly it will become (context gets lost, you start having to interrupt people from other work, and after weeks/months pass by, it’s more likely that people and knowledge will leave).
That’s why it’s important to always review your feedback loops and ask yourself (like we would in any great retro)— how could we improve?
Automated testing in PRs? Pairing? Mobbing? Automating linting and unit testing in IDEs? Contract Testing? Thinner Vertical Slices of value to the end user? Compliance and Security rules baked into your pipeline in dev?
