This is a blog post where I am describing my experience with releasing software. I am sure that you will find other more formal, more full-blown articles but the staff you will read here are based on my personal work background and reflect the reality at work (at least my reality).
Please be aware that this blog post is not discussing many aspects of the releases – the delivery audience (e.g. internal, insider, stable), the release size (e.g. monolith delivery, microservice update, on-premises software), the release branches strategy, the release testing process and many, many other small details. It is solely discussing
the frequency of the delivered software.
Usually, every software you will write for the enterprise, your employer, your customer will be released sooner or later in one or the other form, somehow. My definition for released software is “software which is now used from the end-user and now is doing the real work”. Everything that is made as an internal release, test release, sprint preview release etc. is not a real release.
I.
The first model of releasing is “reactive release”. Basically, you wait until someone requests the software, e.g. a manager is nagging on you, a customer sends a reminder for something to be delivered, support is writing about some important bug. In these situations, the development almost has no control over the process and everything is based on the circumstances, usually made in the last possible moment. And “yes”, I worked in such an environment… Looking back, this sounds crazy. The majority of our releases were based on events. Very, very rare the product was just ready for release. My explanation for all this is the bad development process we had combined with the weak management and lack of development resources.
Pros:
- N/A. I don’t find anything good here.
Cons:
- Development can’t plan anything
- Most of the time is spent in fighting fires
- The developers look “unprepared” in the eyes of the business
II.
The next model is a “high-frequent release”. We were doing a release every second day i.e. every Tuesday and Thursday, sometimes even more often. There were no exceptions, no excuses and the only allowed holiday from this busy schedule was the time around New Year when most of the stuff is any way out of office. I think this approach teaches the discipline to have always shippable software but also creates an awkward situation where you can’t do big changes due to the short release cycles. The usual workaround that we were using was – the “feature toggles”. With the help of some guard variables (the feature toggles), we were able to secure the new code to live in production before it was really ready to work properly. All this was awesome, but as I said sometimes was hard to solve complex problems while running in a high-pace. This release cycle model is suitable for online services under high-load where changes from a couple of weeks can be uncrackable in case some weird performance issues.
Pros:
- The development learns to be ready with shippable software at any time
- Small incremental changes can be monitored easily in case of problems
- Allows changing everything overnight
Cons:
- Hard to deliver big features at the same time with the frequent releases
- It can be distracting and less efficient
- Sometimes requires huge coordination efforts between the developers who are submitting changes
III.
The “low-frequent release” is the opposite of “high-frequent release”. In my case, we were shipping the software twice per yer aka as GA (general availability) release. In many cases, this looks like the following: you are developing 3-4 months and then the last 2 months you are fixing bugs, stabilizing the software, doing the optimizations and so on. I don’t like this approach because I like a much more dynamic environment with frequent feedback. This is simply not my style of work. I am more a person based on collaboration and frequent feedback. However, I see how some people will like this release type.
Pros:
- Complex features can be developed without additional pressure
- There are no excuses that something cannot be delivered (this is a very optimistic statement, I will say 🙂 )
- A lot of “manual” testing assures that everything works. There is a budget for that.
Cons:
- Generally a very slow process
- A slow or missing feedback loop
- Long living branches which should be supported for years. E.g. GA2018.1 will be actual for someone for several years
- Somehow the story “repeats” every year over and over
IV.
And the last from my experience is “release multiple times per sprint, aka when a story is ready”. This means that there are no formal deadlines but when we are ready with something like a “feature” we will ship it without to wait on something else. Someone can confuse this with “reactive release” but they are not the same. In this model, the developers have control over everything because the foundation of the work is the Scrum sprint. We use bi-weekly sprints and we try to scope a delivery in the boundary of the sprint. To be honest, sometimes this is almost impossible. Stuff planed for 1 sprint a prolonged in 2 and etc. However, sprint dynamics is something I like. If the team is following the Scrum framework tightly, the infrequent progress sooner or later will become more predictable which means also more predictable releases.
Pros:
- Easy to adapt. You can do a frequent release after a short story or you can “wait a few weeks” after something big is finished
- High satisfaction in the development team, because you release when you are don
- Business and development collaborate on the right pace
Cons:
- Infrequent
- Sometimes releasing “whole” features can be dangerous
- Requires implementing Scrum process (maybe, you don’t have it your organization…)
Conclusion
I hope that you found the best release process for you. In my case, I am for something between II. and IV. – “high-frequent release” and “release multiple times per sprint, aka when a story is ready”. Both reflect my understandings and values as a software developer and I thoroughly believe that the truth is in the middle, between both models.
radoslav.dk 