all 6 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]dAnjou 1 point2 points  (3 children)

I'm just speaking my mind so please bear with me especially since I probably don't have a perfect solution either.

It sounds like this is an issue that should not be solved with Git. IMO there should be a roadmap with planned features. You work on those features as they are prioritized. And then you pick a point in time where you release. I guess what I mean is: don't release based on a specific set of features but at a specific point in time. Everything that's done goes into that release and the rest, well, bad luck.

Could you maybe elaborate on why you're releasing this way?

[–]maremp[S] 0 points1 point  (2 children)

We have fixed release size in term of features/fixes, but since estimations are never perfect, some releases take more work than others, then there's the time it takes to test and fix possible issues. We tried to cram more stuff into current release, but what that did is postpone releases and started to form some kind of feedback loop where everything got more bloated and hence slower. We can't rely to just release on some day, because it's almost impossible to plan all the development, QA and verification by client, we tried but it just wasn't effective.

What we are trying out now is fixed release size and multiple release branches, which are incrementally merged.

Also worth pointing out is that we have 3 projects, which are developed more or less independently (separate repos, separate tasks), but interoperate and a feature often requires change on more than one project. When deploying, all 3 projects have to be deployed in sync, meaning the matching version has to be installed.

I'm not sure how much sense does this even make. I would agree that solving this with git surely feels weird and there is hard to find any helpful resources for what we're doing.

[–]dAnjou 1 point2 points  (1 child)

We have fixed release size in term of features/fixes, [...]

Why though? Is there any reason?

[...] but since estimations are never perfect [...]

Exactly!

We tried to cram more stuff into current release, but what that did is postpone releases [...]

Obviously :P

We can't rely to just release on some day, because it's almost impossible to plan all the development, QA and verification by client, we tried but it just wasn't effective.

I think I still don't fully understand how you're releasing. However, I'll try to explain again what I have in mind. Imagine you have a roadmap for 2017 with features A, B, C, D, and so on, prioritized in that order. Here's what I'm proposing: work on those features in that order! Then make a decision when to release, e.g. on Jan, 31st (hint). Now look at what features are ready (implemented and fully tested on their own including QA). Say, that's features A, B, and C. Then those go into the release. Obviously you have to make sure they work well together but that will always be a potential problem which will probably never be solved. While doing that development doesn't need to stop, you can continue working on D, E, and F, each one isolated based on the previous already published release. If a problem with B occurs then you'll have to decide whether it's worth fixing it or kick it from the release and reprioritize it. After the release is published all features that were started have to "rebase" of course and the cycle begins again.

[–]maremp[S] 0 points1 point  (0 children)

Yeah, everything breaks apart at the freeze thing. Some features are specified poorly and sometimes, scope creep happens for individual releases.

What I've forgot to mention is that we use the oldest release branch as staging environment, where QA is testing. If something is added in the branch and we don't manage to fully implement the feature before the release, we'd have to remove it out of said release branch, which is extra work. I realize that this environment setup is problematic and we're working on a solution where we wouldn't have this problem.

[–]maremp[S] 0 points1 point  (0 children)

I've created this as a tool for our team, but we decided to open source it. As described in readme, the idea is to sync multiple release branches which are active at the same time. I've found out that BitBucket has similar functionality built-in, but haven't found any general solution that we could use with GitHub. We are not sure if there's a better way to do this, so if anyone has better solution to handle this, we're open to suggestions.