4 ms·

Additional, practical issues that teams have to overcome, regardless of "continuous" delivery, are: * what is being tested by QA/Product Owner/clients etc righ

by berkes 6y ago

Additional, practical issues that teams have to overcome, regardless of "continuous" delivery, are: * what is being tested by QA/Product Owner/clients etc right now? What do we do when they actually have feedback that needs fixing? * how to keep your modifications/patches to SomeUpsTreamSoftware manageable? * How to deal with parallel development by a team of four? Of twelve? Should all work halt until your PR is merged? What if there are conflicts? How to handle longer lived development? All of these are hardly ever covered by "keep it simple". Turning that "keep it simple" model into a giant mess of rules, guidelines, scripts and whatnots. Basically a very poor version of Git flow. Yes. Git flow is often overengineered for CD types of workflows. But it does have all the cases and situations covered that you will eventually run into, and that your homebuilt "simple" flow has not. Edit: to be clear: there are solutions for all my points in your Simple Workflow, certainly. But here's how git-flow helps: * release-branches are ideal for putting work in front of stakeholders before release. Allowing improvements on the release. Even in a CD workflow, having something that is separated from "mainline" during the release-window is a good idea. A release-branch is just that. having a separate mainline where during that time new releases can be made is smart too: you don't want to be forced to wait for feature X to land before you can roll out some important fix. I.e. release, master and hotfix branches. * support- branches in addition to feature branches allow easy rebasing when upstream changes and you need time to re-apply your patches and customisations. You can e.g. branch off a "support-3.1.4" off the 3.1.4 release from upstream and apply your feature/awesome-hack-x on that. * feature branches are ideal for parallel development. Being able to merge into a branch that does not immediately release (separated from mainline) is smart, because it allows multiple team members to merge to and then make a release. i.e. "development" and "feature"

Silhouette 6y ago
I strongly agree with the parent comments in this thread. There are many situations where a very simple branch strategy isn't enough. Another one that I haven't seen mentioned yet is when your software has to be deployed to multiple targets, and each needs the same foundation but also some target-specific adjustments. Maybe you're going to run on different OSes and need to use a different UI on each OS. Maybe you're writing firmware for a range of similar products and each product has its own quirks. Maybe you need to change some code on platform X because there's a known compiler bug where the normal code doesn't work. There are plenty of practical circumstances where this sort of thing can happen. You want to control and ideally automate as much of it as you can, for the same reasons as any other deployment process, and more complicated but systematic branching strategies are often useful for that.
- rkangel 6y ago
  Handling variations (e.g. multiple targets) surely isn't the responsibility of the version control system? If you need to build for multiple targets or have different special versions, than write your build scripts to produce multiple versions. The Linux kernel builds for lots of targets, but there is only one master tree for it.
  - Silhouette 6y ago
    As ever, the devil is in the details. If you're just talking about using different build tools, sure, maybe you do that at the level of some separate scripts. If you have mostly common code but a few relatively small adjustments you need for each platform, where better to track that you have merged the correct adjustments into any given build than in your VCS? If you have larger differences between platforms, maybe you factor out parts of your code into separate components and then build only the combination of components you need for any given target. These strategies are not mutually exclusive. Your Linux kernel example might be quite apt here. While the authoritative version may have a single master, how many distros maintain their own fork of the kernel and probably numerous other packages, merging in changes from upstream regularly, but only ever making releases of their distro from their own forks where perhaps they have their own bug fixes or other adjustments applied?
    - rkangel 6y ago
      But how does ongoing development work? You have changes, now you need to merge them into every branch. How do you know which ones are going to break the build, how do you know which ones just aren't going to merge due to divergence? I have a horror of this due to having experienced a strategy where the team took a new (subversion) branch every time they started a new project (i.e. were building a new device in the same family). You had multiple branches with divergent development but lots of common functionality. If you wanted to fix a bug common to all the systems you had to fix it 4 times. I absolutely believe that there are better ways of implementing that approach than they used, but I also am convinced through experience that you should have one single line of development and everything else is just 'views' on that (e.g. point release branch is just a view master that is frozen, plus some filtered recent history). To take your Linux kernel example - the various forks (I'm working with the Xilinx Petalinux Kernel now) don't really fit into the normal model. They're a combination of a release branch and a feature branch - they take the Linux Kernel at a certain time, then add some patches on top. Those patches then usually get submitted (indirectly) back to Linus so that they join the master path of development. That means that other people benefit from them, and refactor them when appropriate.
TheCoelacanth 6y ago
> How to deal with parallel development by a team of four? Of twelve? Should all work halt until your PR is merged? What if there are conflicts? How to handle longer lived development? I'm following the process they described on a team of about 40 developers, and it actually greatly reduces those problems by forcing people to simply not to have long lived branches. Git flow just puts off the pain of working with that many people until later and creates a giant train-wreck when you finally try to incorporate your feature branch. If you have a large feature, then use feature flags to let you release it to production dark before it finishes. If you want to do a large refactor, either find a way to do it incrementally or keep both the old and new versions in place together until the new version is completely done. > release-branches are ideal for putting work in front of stakeholders before release Feature flags are better for this. If you don't want users to see an incomplete feature, that doesn't mean they have to be using a version of the software that doesn't support that feature. You can just explicitly hide the feature from certain classes of users.

by berkes 6y ago

Silhouette 6y ago

I strongly agree with the parent comments in this thread. There are many situations where a very simple branch strategy isn't enough. Another one that I haven't seen mentioned yet is when your software has to be deployed to multiple targets, and each needs the same foundation but also some target-specific adjustments. Maybe you're going to run on different OSes and need to use a different UI on each OS. Maybe you're writing firmware for a range of similar products and each product has its own quirks. Maybe you need to change some code on platform X because there's a known compiler bug where the normal code doesn't work. There are plenty of practical circumstances where this sort of thing can happen. You want to control and ideally automate as much of it as you can, for the same reasons as any other deployment process, and more complicated but systematic branching strategies are often useful for that.

rkangel 6y ago
Handling variations (e.g. multiple targets) surely isn't the responsibility of the version control system? If you need to build for multiple targets or have different special versions, than write your build scripts to produce multiple versions. The Linux kernel builds for lots of targets, but there is only one master tree for it.
- Silhouette 6y ago
  As ever, the devil is in the details. If you're just talking about using different build tools, sure, maybe you do that at the level of some separate scripts. If you have mostly common code but a few relatively small adjustments you need for each platform, where better to track that you have merged the correct adjustments into any given build than in your VCS? If you have larger differences between platforms, maybe you factor out parts of your code into separate components and then build only the combination of components you need for any given target. These strategies are not mutually exclusive. Your Linux kernel example might be quite apt here. While the authoritative version may have a single master, how many distros maintain their own fork of the kernel and probably numerous other packages, merging in changes from upstream regularly, but only ever making releases of their distro from their own forks where perhaps they have their own bug fixes or other adjustments applied?
  - rkangel 6y ago
    But how does ongoing development work? You have changes, now you need to merge them into every branch. How do you know which ones are going to break the build, how do you know which ones just aren't going to merge due to divergence? I have a horror of this due to having experienced a strategy where the team took a new (subversion) branch every time they started a new project (i.e. were building a new device in the same family). You had multiple branches with divergent development but lots of common functionality. If you wanted to fix a bug common to all the systems you had to fix it 4 times. I absolutely believe that there are better ways of implementing that approach than they used, but I also am convinced through experience that you should have one single line of development and everything else is just 'views' on that (e.g. point release branch is just a view master that is frozen, plus some filtered recent history). To take your Linux kernel example - the various forks (I'm working with the Xilinx Petalinux Kernel now) don't really fit into the normal model. They're a combination of a release branch and a feature branch - they take the Linux Kernel at a certain time, then add some patches on top. Those patches then usually get submitted (indirectly) back to Linus so that they join the master path of development. That means that other people benefit from them, and refactor them when appropriate.

TheCoelacanth 6y ago

> How to deal with parallel development by a team of four? Of twelve? Should all work halt until your PR is merged? What if there are conflicts? How to handle longer lived development? I'm following the process they described on a team of about 40 developers, and it actually greatly reduces those problems by forcing people to simply not to have long lived branches. Git flow just puts off the pain of working with that many people until later and creates a giant train-wreck when you finally try to incorporate your feature branch. If you have a large feature, then use feature flags to let you release it to production dark before it finishes. If you want to do a large refactor, either find a way to do it incrementally or keep both the old and new versions in place together until the new version is completely done. > release-branches are ideal for putting work in front of stakeholders before release Feature flags are better for this. If you don't want users to see an incomplete feature, that doesn't mean they have to be using a version of the software that doesn't support that feature. You can just explicitly hide the feature from certain classes of users.