Continuous Delivery from months to weeks

In moving to CD, teams often experience some early success. Cutting lead time from 6 months to 3 months turns out to be easy. That’s just smart scope management and getting people to actually talk to each other. But going from months to weeks, or even to days? Most teams hit a wall. This proves to be a chasm many cannot cross.
The good news is that the teams who are doing this all have one thing in common. They all like to fail fast.
Build-test-release cycles have many activities, people and handoffs. With all those moving parts, many teams take days, weeks, or months to verify that a code change is production worthy. Failing late like this is crazy expensive, and it compounds as the failures stack up. Production-ready builds become highly elusive beasts.
Teams that succeed at CD design their build-test-release cycle with an eye towards failing as early as possible. Early failure is cheap and easy to fix. Detecting and fixing errors quickly makes it feasible to be production-ready most all the time.
So let’s look at how teams fail fast.

1) Relentless automation

Automation eliminates dull work and the waste of human error. It shortens feedback loops and ensures repeatability. This adds up to failing faster. When you do fail, the repeatable nature of automated tasks allows you to easily track down the problem.
If you aren’t committed to automation, the rest of this post probably isn’t for you. Come back when the lack of automation gets in your way.
What should you automate? Everything! Packaging, testing, provisioning, deployments, configuration. And treat your automation scripts, your infrastructure, as production code. And store it all in a source repository. By the way, if you don't have a team that can automate, your top priority shouldn't be tooling. Get the right people first.

2)  A Continuous Delivery tool to optimize you build-test-release workflow

Commitment to automation is not enough. Scripting and automated testing is mostly a localized activity. Something needs to tie it all together. It’s nearly impossible to get to stress-free weekly/daily releases without quality end-to-end tool support. We call these tools Continuous Delivery tools. Thoughtworks Go is a Continuous Delivery tool because it can help you with the following:

a) Break silos  - Model workflows across all the teams. Get everyone to collaborate at a deep level. There is no more throwing it over the wall.
b) Model every workflow step to fail fast - Support intelligently sequenced and parallel work. No matter how you’ve gone about automating, each step can be designed to fail quickly.
c) Self-service - Waiting on another team sucks. e.g., your testers should be able to deploy whatever build they please to whatever environment they please.  
d) Know what is going on:

• Which dependency or commit broke the build?
• Who broke the build?
• What's the difference between these 2 builds?
• Which features and bug fixes are in this release candidate?
• Which version of our software is running in this environment?
• Who deployed in this environment and when?

Automation on its own won’t get you to weeks or days. Teams need a common and useful tool to model, execute, see, analyze, and continuously improve their end-to-end workflow. Without such a tool, the forest cannot be seen. Improvements cannot be made.
Getting to a state of a fully automated, sensibly orchestrated end-to-end workflow can be a lot of work. But with the right people and the right tools, like Go, you can get there. And you can get there incrementally -- it doesn’t need to be big bang. Trust us, it’s worth it. And it’s the only way you will ever achieve Continuous Delivery.

See how the newly released Go 12.3 can help you to cross the CD chasm and optimize your build-test-release process.