3 ms·
This still sounds like an anti-pattern to me, at least in a typical web app. I’ve seen a very similar workflow used in a previous org, and the main benefit was
by cactus2093 7y ago
This still sounds like an anti-pattern to me, at least in a typical web app. I’ve seen a very similar workflow used in a previous org, and the main benefit was that it limits the number of times you have to cross your fingers and hope for the best (which is obviously masking other reliability problems). Merging each feature branch wasn’t scary because it wasn’t going to deploy yet, but that means it incentivizes somewhat of a “not my problem” culture. Then at some point someone builds up the courage to merge the develop branch to master and you hope for the best. Repeat every few days.
There was also some wishful thinking about doing more qa testing than anyone actually did. The develop branch would immediately deploy to the staging environment, so someone might have tested new features there before they ship to production. But if there’s no rigorous process around exactly what needs to be QA’d and whose responsibility it is, then let’s be realistic, it’s not gonna happen.
The downsides are that release times were less predictable, deploys were bigger which means potentially more difficult to trace down bugs that do show up and roll back when needed, and things would get delayed for no reason. Oops, I thought I shipped that thing for marketing a few days ago but nobody deployed the develop branch since then.
Developing small features right into develop sounds like a bit of an issue on its own too. Seems like you’re not quite confident enough to deploy it right away, but it’s also presumably circumventing the regular code review process so it’s not going to get reviewed.
The only reason I can see for why these downsides would be worth it, is if you have some hard constraint that you can’t deploy very frequently (for instance releasing a downloadable desktop app or mobile app), and/or you have a formal, rigorous manual QA process when merging from develop to master.
- theK 7y agoI don’t get it. I manage multiple teams that are doing web apps. Many of those use Gitflow like life cycles and none of them has issues based on their lifecycle. Some of them do release branches, some not. Some do ff-only other don’t. Doesn’t really matter as long as it is efficient (simple) enough. Of course we are also not only deploying the long lived branches but actually every push results in some sort of ephemeral environment being spun up tested and spun down again (or stick around in car of failures) so Feedback on what is happening is quite direct but any way. If you help teams find a pragmatic lifecycle for them you can avoid all the perceived issues of any cv lifecycle. One exception might be the occasional group of optimists trying their hand at micro repos. These are just bound to blow up :-D unnecessary conplexity and all...
- cloverich 7y agoIn my experience, an additional gap between working directly on master is many teams don't understand the concept of promoting builds. So e.g. you can build on every commit, then _after the fact_ promote one to an actual release (without re-building). This isn't suitable for _every_ situation, but it is for all the ones I've encountered so far. Relatedly is "release branches". An alternative is to simply tag the release that went out, which is the same thing. If it needs a hotfix, you branch off the tag, fix it there, then apply that fix (cherry-pick or redo) back to master. Overall, IME the biggest benefit is the cultural changes it instills in the team: Everything must be good enough to release, and everything goes to the same place. For projects that can afford it (again, most can I bet) its a huge drop in mental effort to understand the state of the world at any given time.