Getting into production sooner should be part of our business plan.
Rather than spending lots of time getting all planned features 'finished', we should have a plan for slowly rolling out incremental changes. In doing so we would have more confidence that the features we were releasing would not break something in production and make it difficult to rollback. In effect we want to avoid ending up with a 'big bang' rollout.
The following steps could be a useful plan of action to take:
- define code 'boundaries'
- filter traffic by 'funnels'
- build features, then deploy them within our secured boundaries
Note: I've since discovered that this approach is a form of Strangler Pattern. I've been using it for years but was unaware that it had a name and that Martin Fowler was responsible for that way back in 2004!
Identify areas of the existing code base where new changes (e.g. replacement of existing services) will need to happen, and ensure their are appropriate code branches in place.
In essence, build a wall around where your new code will end up.
Define what users (or general traffic) can access the code that sits inside of the defined boundaries. For example, maybe just traffic from your own team should be able to penetrate the code branches (via some form of authentication process: self-signed certs, cookies or a custom header etc).
Important! make sure your funnels are working and then code you place within these new 'boundaries' does not break anything in production (have tests written to ensure this).
As the project reaches a state where it can be exposed to more uses, you update the 'funnel' to allow more an more throughput. Thus increasing the allowed traffic range (e.g. not only your team can access it, via authentication, but so can multiple teams within your organization; then moving forward you can replace the authentication process with a locality check -- so users in Australia get the new feature, etc).
While you have the boundaries for your new code defined, and a small funnel in place to control the traffic, you can then start quickly deploying new code without fear of it breaking anything in production.