When to have Scheduled Releases (vs pushing to production when a ticket is complete)?

Question

UPDATE I totally get why this question could/should get dinged ... but hey, if you feel inclined to vote down this question, can you also provide some feedback on where a better forum could be for me to take this question?

I am at the start of a new effort to create an internal product for my company. So, right off the bat, the stakes aren't crazy high since my customers are my co-workers across the org (I personally work with a team of 8 developers).

Our main focus is to combine our multiple (~4) services under one, unified product (so a lot of refactoring, merging, and complete rewrites of code).

We're starting to cobble together the plan/strategy for this new product and I've been questioning a lot of our existing strategies to see if there is an advantage to another approach.

When is it appropriate to have scheduled releases (vs. pushing to prod when a sizable effort has been completed) ?

A stakeholder asked me about a release schedule and my first thought was, "Why don't we do this?"

We can definitely continue with ad-hoc pushes, but is there a value-add to telling the business owners/stakeholders that they should be able to expect a release every third Monday of a month (for example)?

Answer 1

Well, the only real values I can think of would be that your stakeholders know when to expect a new release and you have to ensure some development discipline to get things done before a certain release date is hit.

Your stakeholders cannot know when a sizable effort has been completed, they won't have enough insight to know and probably don't really care to track the progress all the time. Of course, you can make sure they will get notified about new releases as soon as they are available but this requires additional effort from your side.

And if your development time is unbound, you may suffer by a typical development weakness that you try to make a feature better and better and better but it will never complete as no matter how good it already is, you can still make it even better if you invest even more time. Having a hard time limit shifts the focus from "it's done when it is done" to "it is done at that date and we have to see what can be done in the remaining time, possibly making compromises and ship a less elaborated feature but at least we ship it at all".

And as usually, if option A has advantages/disadvantages and so does option B, you can choose A, you can choose B, or you try to combine them to create option C:

Create daily/weekly/monthly builds. Those builds represent a fixed release cycle and they will force some developing discipline as you need to make sure that whatever big change you are starting, it must either be done by the next release date or it must be on a feature branch so you can release without that change. Also the code base must always be in a built-able and run-able state by the end of the current cycle. However, those releases are not versioned, they are only identified by their release date and they only have a very short list of changes. And whenever a sizable effort has been completed, you make a real release with a new version number and provide more elaborated release notes and documentations if required.

Answer 2

Scheduled releases are good for planning.

Say you have an eCommerce site and the big boss has asked for a new feature "size charts"

The Big Boss will be telling investors that the new "size chart" feature will make the company more valuable, they should invest more! The investors will want to, know when it will be done, the marketing dept will be producing flyers, the sale dept will want to do a demonstration at the big tech conference etc etc.

This all filters down to the dev team who have to make it work along with a bunch of other stuff and the question on everybody's lips "will be when will this be ready?"

Now if you do continuous deployment, agile sprints or whatever the answer is very fluid. "it will be done when its done"

If you have monthly/quarterly releases it gets a bit more concrete. Will feature X be in this months release? What features can we announce at the conference? When should those flyers go out? We had to roll back release X?!?!? OMG WHY DIDN'T YOU TEST MORE?!?! etc

Scheduled releases help everyone sync up a bit more and maybe put a bit more concentration into delivering a tested and polished thing or understanding that actually there are a whole bunch of things that need to get done, not just the one you are interested in this week.

Of course you can do the same thing with CD or just release when its ready, it maybe takes a bit more understanding to make it work.