3 ms·

Did I read it correctly that in first iteration they merged "NOT TESTED" code into master ? Who would ever think it's a good idea ?

by pojzon 7y ago

dkoston 7y ago
That’s what trying to get at in a “more polite” way. Many people use a “develop” branch to stage changes before master so they can run through CI. I’m curious as to why they used an untested queue instead. It seems like they wanted to cherry pick what commits made it to master rather than going in chronological order. What’s odd is that they seem to characterize this as a tools issue rather than a process issue. There are plenty of CI/CD tools that allow for a similar or the same workflow as what they created. It’s also kinda scary that there’s not an emphasis on the overall SDLC and how the specific attributes of a branch or commit should/shouldn’t affect the process. You’d think at 1000 developers it’d be very important to define what is “launchable” as well. Haven’t worked with 1,000 on the same project but even with 20+, the standards and practices around development were always more important than the tooling. Tooling was just meant to represent workflows that were already defined.
wvanbergen 7y ago
The branches that are being merged are tested, also in the first version. However, different branches can conflict with each other, and break the master builds. This was happening often enough for us to want to prevent this. The simple way would be to rebase your branch (or merge in master). However, with the amount of changes that are being merged, by the time the CI result comes in for your rebased branch, the tip of master is already changed making the CI result obsolete. So we went for the queue approach instead.
- pojzon 7y ago
  Dont know if I respond to author, but either way the end solution was to merge into semi master and run CI before merging to master.. So overall you came to conclusion that what you explained even if can fail is pretty much the best way you can do it.. (rebase just custom..) Overall DevOps principles are proven to simply work, you just have to follow them..
byroot 7y ago
It was tested. It's simply that between the time you pushed on your branch, and the time you merged, many other commits made it to the master branch, potentially breaking your branch.
- pojzon 7y ago
  That pretty much forces tooling to try to rebase and run CI either way ? If it cannot rebase its up to the developer to fix his branch. Master should be always in a state of release at any moment. I just cannot imagine it was an unknown practice for some.
  - byroot 7y ago
    Except that with the amount of activity on the repo it's simply impossible. Every new merge on master would require to rebase several hundred branches being worked on or awaiting reviewed. Multiply this with the hundreds of commits merged on master every day and you end up with way too much CI jobs to run.
    - pojzon 7y ago
      Its not impossible.. thats what they ended up with either way.. And how do I know its possible ? Well I have over 2000 developers working on the same codebase in my current company. I work as a devops and this conversation is stupid..

Did I read it correctly that in first iteration they merged "NOT TESTED" code into master ? Who would ever think it's a good idea ?

by pojzon 7y ago

Did I read it correctly that in first iteration they merged "NOT TESTED" code into master ? Who would ever think it's a good idea ?

dkoston 7y ago

That’s what trying to get at in a “more polite” way. Many people use a “develop” branch to stage changes before master so they can run through CI. I’m curious as to why they used an untested queue instead. It seems like they wanted to cherry pick what commits made it to master rather than going in chronological order. What’s odd is that they seem to characterize this as a tools issue rather than a process issue. There are plenty of CI/CD tools that allow for a similar or the same workflow as what they created. It’s also kinda scary that there’s not an emphasis on the overall SDLC and how the specific attributes of a branch or commit should/shouldn’t affect the process. You’d think at 1000 developers it’d be very important to define what is “launchable” as well. Haven’t worked with 1,000 on the same project but even with 20+, the standards and practices around development were always more important than the tooling. Tooling was just meant to represent workflows that were already defined.

wvanbergen 7y ago

The branches that are being merged are tested, also in the first version. However, different branches can conflict with each other, and break the master builds. This was happening often enough for us to want to prevent this. The simple way would be to rebase your branch (or merge in master). However, with the amount of changes that are being merged, by the time the CI result comes in for your rebased branch, the tip of master is already changed making the CI result obsolete. So we went for the queue approach instead.

pojzon 7y ago
Dont know if I respond to author, but either way the end solution was to merge into semi master and run CI before merging to master.. So overall you came to conclusion that what you explained even if can fail is pretty much the best way you can do it.. (rebase just custom..) Overall DevOps principles are proven to simply work, you just have to follow them..

byroot 7y ago

It was tested. It's simply that between the time you pushed on your branch, and the time you merged, many other commits made it to the master branch, potentially breaking your branch.

pojzon 7y ago
That pretty much forces tooling to try to rebase and run CI either way ? If it cannot rebase its up to the developer to fix his branch. Master should be always in a state of release at any moment. I just cannot imagine it was an unknown practice for some.
- byroot 7y ago
  Except that with the amount of activity on the repo it's simply impossible. Every new merge on master would require to rebase several hundred branches being worked on or awaiting reviewed. Multiply this with the hundreds of commits merged on master every day and you end up with way too much CI jobs to run.
  - pojzon 7y ago
    Its not impossible.. thats what they ended up with either way.. And how do I know its possible ? Well I have over 2000 developers working on the same codebase in my current company. I work as a devops and this conversation is stupid..