When was the last time you deployed to production? The last time before that?
When you deployed, did you feel a certain tension, an uncertainty of how the changes would behave in production?
We’ve all been there, we were afraid to ship a certain change to production. Maybe the change was too big, maybe too much happened in the code base since the last deployment, maybe the code isn’t fully tested and still somewhat experimental.
There are a ton of reasons why shipping new code to production is something to be wary of. Complex processes and dependencies, lack of automation, lack of monitoring infrastructure, lack of confidence in code changes, slow and complex test suites.
But there are solutions for a lot of these issues, the trouble sometimes is that they take time to implement, they take time away from what’s considered to be the most important task at hand: ship more value to the customer.
There are tradeoffs involved, but not keeping a good eye on your ability and confidence to ship will hurt your ability to get changes to production as quickly as possible.
It doesn’t matter if you ship once a day or if you do a hundred deployments a day. Being able to get a change into production quickly, no matter if it’s a new feature or an urgent bug fix, is an important long term asset for your team’s happiness and productivity.
Can you ship any code changes quickly and with confidence?
If not, what’s keeping you? Let us know in the comments!
We can help get rid of the fear of shipping.