4 ms·

Hi, This flow works under some conditions only: * You have working CI/CD that you can trust * You do not have to support old versions of the software Exampl

Hi, This flow works under some conditions only: * You have working CI/CD that you can trust * You do not have to support old versions of the software Example of some situations where these conditions are not met: * Installs of your software are not reachable over the Internet * Your software needs manual testing or qualification before deployment * You do not handle your software's deployment; your client does. In those situations, you may need to maintain release branches, and backport fixes, etc.

ollyculverhouse 6y ago
We perform manual testing and qualification on feature branches (but deployed to a qa or staging environment). The thing that really helped us was separating the idea of environments and branches.
rakoo 6y ago
Not the one you're replying to, but there are a few points: - This flow applies more for a service or a website, where there is no problem of distribution: the distribution is done the moment your user reaches your website/service. - In the case of a website there is one website. In the case of services there may be multiple versions, but they exist together in the same file tree. Fixing an issue on an old version means fixing the issue on specific files; when they're pushed on master the users will get the fix - An alternative flow of having to manage multiple versions in parallel is to use feature-flags to compartmentalize sections of code that aren't tested yet or not even functional yet. That way you can have everything on a single branch and make all the code aware of each other. Feature flags can be activated gradually in qa environment, then in staging, then in some customers only, etc... to iron out the bugs as deployment goes. Note that this way of doing is also adapted for traditional installable software, see Firefox and Chrome and their myriads of activation flags.
- Silhouette 6y ago
  An alternative flow of having to manage multiple versions in parallel is to use feature-flags to compartmentalize sections of code that aren't tested yet or not even functional yet. The advantages of feature flags over feature branches are mostly an illusion, though. Sure, if you're updating your code in co-ordination with updating some external system, such as a database migration, then sometimes deploying in stages with multiple versions of some functionality running concurrently during some of the intermediate stages is more-or-less the only way you can do it without incurring downtime. But otherwise, even if you have 10 teams and each hides their changes behind a flag and pushes to master instead of a feature branch, you still have an exponentially growing number of combinations and they're still not all being tested in arbitrary combinations. Turning the feature flag on is then little different to merging in a feature branch: it's still a time when things can go wrong. It's just that now they're going wrong on your master branch and screwing things up for everyone else, too.
  - AaronM 6y ago
    Your missing the big advantage. Feature flags should be toggled without doing a deployment/release. That way you can turn it on, monitor and turn it off if it doesn't work right. In addition, feature flags should only live until the feature is working. The flag should be removed once that has happened.
    - Silhouette 6y ago
      Your missing the big advantage. Feature flags should be toggled without doing a deployment/release. That way you can turn it on, monitor and turn it off if it doesn't work right. So you're essentially advocating testing new code, or new combinations of code changes, in production?
      - the_new_guy 6y ago
        I think what he's saying is from a production standpoint, the new feature is feature-flagged, and that feature flag has the feature disabled. From a test environment standpoint, you can then enable that feature flag/combination of feature flags, test until your heart is content, and only enable in prod if things go pear-shaped. And if they do, well...it can be as simple as turning that feature flag back to disabled, unless state changes prevent that.
        Silhouette 6y ago
        It's obviously possible that there's an effective development process in here somewhere that I just haven't come across myself, but I still don't see it. For a feature flag to be useful compared to the typical setup where you have a feature branch and then rebase that onto master from time to time until you're ready to do a fast-forward merge, you would need to be testing multiple features concurrently before any of them is merged back to master. Testing all possible combinations of unmerged features in development is an exponentially difficult problem, so surely no-one is doing that. However, even testing selected combinations still requires someone to be aware of everything that is going on in enough technical detail to highlight potential trouble areas in time to take useful action that would become more difficult once some of those features start to get merged in. Assuming you have a large enough project that co-ordinating different ongoing development work isn't just handled via informal discussions anyway, that would mean someone has to be identifying risky combinations that could benefit from testing in advance, and someone has to be responsible for doing that testing, and someone has to be responsible for addressing any issues that are discovered as a result. Does anyone here work in a development group that actually does this? Meanwhile, the cost of using feature flags routinely is clear: every time you do any significant development work, you have to bracket all affected code with a new flag, and someone has to coordinate those flags and make sure they're all tidied up with code left in the "on" mode by release time.

ollyculverhouse 6y ago

We perform manual testing and qualification on feature branches (but deployed to a qa or staging environment). The thing that really helped us was separating the idea of environments and branches.

rakoo 6y ago

Not the one you're replying to, but there are a few points: - This flow applies more for a service or a website, where there is no problem of distribution: the distribution is done the moment your user reaches your website/service. - In the case of a website there is one website. In the case of services there may be multiple versions, but they exist together in the same file tree. Fixing an issue on an old version means fixing the issue on specific files; when they're pushed on master the users will get the fix - An alternative flow of having to manage multiple versions in parallel is to use feature-flags to compartmentalize sections of code that aren't tested yet or not even functional yet. That way you can have everything on a single branch and make all the code aware of each other. Feature flags can be activated gradually in qa environment, then in staging, then in some customers only, etc... to iron out the bugs as deployment goes. Note that this way of doing is also adapted for traditional installable software, see Firefox and Chrome and their myriads of activation flags.

Silhouette 6y ago
An alternative flow of having to manage multiple versions in parallel is to use feature-flags to compartmentalize sections of code that aren't tested yet or not even functional yet. The advantages of feature flags over feature branches are mostly an illusion, though. Sure, if you're updating your code in co-ordination with updating some external system, such as a database migration, then sometimes deploying in stages with multiple versions of some functionality running concurrently during some of the intermediate stages is more-or-less the only way you can do it without incurring downtime. But otherwise, even if you have 10 teams and each hides their changes behind a flag and pushes to master instead of a feature branch, you still have an exponentially growing number of combinations and they're still not all being tested in arbitrary combinations. Turning the feature flag on is then little different to merging in a feature branch: it's still a time when things can go wrong. It's just that now they're going wrong on your master branch and screwing things up for everyone else, too.
- AaronM 6y ago
  Your missing the big advantage. Feature flags should be toggled without doing a deployment/release. That way you can turn it on, monitor and turn it off if it doesn't work right. In addition, feature flags should only live until the feature is working. The flag should be removed once that has happened.
  - Silhouette 6y ago
    Your missing the big advantage. Feature flags should be toggled without doing a deployment/release. That way you can turn it on, monitor and turn it off if it doesn't work right. So you're essentially advocating testing new code, or new combinations of code changes, in production?
    - the_new_guy 6y ago
      I think what he's saying is from a production standpoint, the new feature is feature-flagged, and that feature flag has the feature disabled. From a test environment standpoint, you can then enable that feature flag/combination of feature flags, test until your heart is content, and only enable in prod if things go pear-shaped. And if they do, well...it can be as simple as turning that feature flag back to disabled, unless state changes prevent that.
      - Silhouette 6y ago
        It's obviously possible that there's an effective development process in here somewhere that I just haven't come across myself, but I still don't see it. For a feature flag to be useful compared to the typical setup where you have a feature branch and then rebase that onto master from time to time until you're ready to do a fast-forward merge, you would need to be testing multiple features concurrently before any of them is merged back to master. Testing all possible combinations of unmerged features in development is an exponentially difficult problem, so surely no-one is doing that. However, even testing selected combinations still requires someone to be aware of everything that is going on in enough technical detail to highlight potential trouble areas in time to take useful action that would become more difficult once some of those features start to get merged in. Assuming you have a large enough project that co-ordinating different ongoing development work isn't just handled via informal discussions anyway, that would mean someone has to be identifying risky combinations that could benefit from testing in advance, and someone has to be responsible for doing that testing, and someone has to be responsible for addressing any issues that are discovered as a result. Does anyone here work in a development group that actually does this? Meanwhile, the cost of using feature flags routinely is clear: every time you do any significant development work, you have to bracket all affected code with a new flag, and someone has to coordinate those flags and make sure they're all tidied up with code left in the "on" mode by release time.