3

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)?

  • 3
    "can you also provide some feedback on where a better forum could be for me to take this question?" Knowing that your question is most probably off-topic here, doesn't automatically imply knwoledge about a better forum wher you can post it. shrug – πάντα ῥεῖ Feb 16 at 12:42
  • 3
    I don't see how this question is off topic. This board is about asking questions about software egineering and proper release management is a very important aspect of software engineering IMHO. Otherwise why would the tags release-management and sdlc even exist if that topic is off-topic here? And why should asking for advantages of a fixed release schedule be off-topic? – Mecki Feb 16 at 15:45
  • Honestly, I got a negative ding within minutes of making this post. Hence the update message. I did try googling this first and one of the links lead me here. So yeah, if someone doesn't like the question they can always ding it. But if there's nothing of value to provide other than "dislike" then what's the point? In a forum built on a community helping each other, shutting someone down/voting someone down without providing additional info is not helpful. So from that, I was willing to accept an error on my part, but I needed to know what I could have done better. – Doug Feb 17 at 4:44
  • Thank you @mecki the tags are a good point. I didn't put them in the system :) – Doug Feb 17 at 4:45
3

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.

|improve this answer|||||
  • I really like the coupling with versioning. As well as how it may enforce a clean repo. – Doug Feb 17 at 4:50
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.

|improve this answer|||||
  • Thanks for the insight! I definitely see the merit in coordinating across multiple teams. And that definitely is something that my team will need to be a part of. – Doug Feb 17 at 4:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.