4 ms·

> Avoid Feature Branches The argument in favour of this advice only checks out when a feature branch is kept out of sync with the main branch. In my experience

> Avoid Feature Branches The argument in favour of this advice only checks out when a feature branch is kept out of sync with the main branch. In my experience, the process that works the best is to rebase the feature branch on top of the main every time there is a divergence, resolving all the conflicts right then and there. > Use a monorepo Definitely - if you have a monolithic implementation that is deployed as a single unit. Otherwise, monorepos start getting in your way pretty soon. > Use feature flags There are pros and cons for this. In my experience, feature flags work best in the front-end, where you want to hide features from certain users at certain times. > Deploy weekly The deployment strategy depends primarily of the type of the product you're delivering. For a standard, vanilla SaaS, the continuous deployment is the most efficient.

ricardobeat 4y ago
I wish more people were comfortable with rebasing. This is my favorite workflow too, but I've never been in a team where we're able to do that as a default, unfortunately it requires an understanding of git that's deeper than the average dev deems worth.
- BerislavLopac 4y ago
  Not necessarily. A lot of developers despise the idea of using git GUIs, but e.g. GitKraken makes rebases - even with conflicts - a breeze.
  - jaxn 4y ago
    Plus you get to say out loud “let’s get cracking’” every time you open it up. Just me?
- gjulianm 4y ago
  But you don't really need rebasing in this case, right? Merging the main branch into the feature branch would work too, and it's not too difficult.
  - ricardobeat 4y ago
    Rebasing is a necessity for this workflow. If every branch has multiple “merge master into …” commits, and they are also merged back into master (without rebasing or squashing) you end up with a huge mess. Reverting anything becomes impossible, and mistakes when merging almost irrecoverable.
    - HWR_14 4y ago
      Is that true? I've never had any problem reverting with the workflow described and I find fixing merge issues to also be trivial. Okay, not trivial, but no harder because I had merged the master onto the feature many times. Why would either of those be harder?
    - P5fRxh5kUvp2th 4y ago
      No it isn't, full stop. What you mean to say is you don't like the way the history looks. That's fine, it's a valid criticism. Calling it a necessity is over the line.
papito 4y ago
The deployment strategy depends on a lot more than that. Team size, team workload, product nature, customer expectations, average story size and complexity. Hard release cadence is amateur hour (outside of major software pieces like operating systems and languages). One release method that I had to install by pulling rank (after non-stop discussions) was the "release when ready" approach. Imagine your scrum board. There is the QA column - all the stories that are currently being QA'ed. Now imagine that during a standup, the QA column is empty - everything has been tested and there are no unstable features in QA. This is when you cut a release. It can be that you release every day, or you may not release for three weeks. It worked without fail, and was insanely flexible, resistant to change in variables.
- BerislavLopac 4y ago
  > The deployment strategy depends on a lot more than that. Team size, team workload, product nature, customer expectations, average story size and complexity. Apart from "team size", every single item on that list is part of the definition of "type of the product you're delivering".

ricardobeat 4y ago

I wish more people were comfortable with rebasing. This is my favorite workflow too, but I've never been in a team where we're able to do that as a default, unfortunately it requires an understanding of git that's deeper than the average dev deems worth.

BerislavLopac 4y ago
Not necessarily. A lot of developers despise the idea of using git GUIs, but e.g. GitKraken makes rebases - even with conflicts - a breeze.
- jaxn 4y ago
  Plus you get to say out loud “let’s get cracking’” every time you open it up. Just me?
gjulianm 4y ago
But you don't really need rebasing in this case, right? Merging the main branch into the feature branch would work too, and it's not too difficult.
- ricardobeat 4y ago
  Rebasing is a necessity for this workflow. If every branch has multiple “merge master into …” commits, and they are also merged back into master (without rebasing or squashing) you end up with a huge mess. Reverting anything becomes impossible, and mistakes when merging almost irrecoverable.
  - HWR_14 4y ago
    Is that true? I've never had any problem reverting with the workflow described and I find fixing merge issues to also be trivial. Okay, not trivial, but no harder because I had merged the master onto the feature many times. Why would either of those be harder?
  - P5fRxh5kUvp2th 4y ago
    No it isn't, full stop. What you mean to say is you don't like the way the history looks. That's fine, it's a valid criticism. Calling it a necessity is over the line.

papito 4y ago

The deployment strategy depends on a lot more than that. Team size, team workload, product nature, customer expectations, average story size and complexity. Hard release cadence is amateur hour (outside of major software pieces like operating systems and languages). One release method that I had to install by pulling rank (after non-stop discussions) was the "release when ready" approach. Imagine your scrum board. There is the QA column - all the stories that are currently being QA'ed. Now imagine that during a standup, the QA column is empty - everything has been tested and there are no unstable features in QA. This is when you cut a release. It can be that you release every day, or you may not release for three weeks. It worked without fail, and was insanely flexible, resistant to change in variables.

BerislavLopac 4y ago
> The deployment strategy depends on a lot more than that. Team size, team workload, product nature, customer expectations, average story size and complexity. Apart from "team size", every single item on that list is part of the definition of "type of the product you're delivering".