5 ms·

> Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team memb

> Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members. I occasionally see statements like this floating around - does he mean: * Devs make their changes locally, commit and push directly to main, and then the CI/CD either notifies them that tests failed or deploys to prod or * Devs make their changes locally, commit and push on a branch, and rapidly (ideally automatically) merge to main if tests pass. This happens on a cycle of minimum coherent set of code changes, not a whole feature at a time or anything like that. The first seems like it would be very frustrating if code with failing tests if pushed with any frequency, but seems to be literally what the phase "work on main" means. I also don't really see a drawback to the second one in comparison.

science4sail 5y ago
> The first seems like it would be very frustrating if code with failing tests if pushed with any frequency, but seems to be literally what the phase "work on main" means. Yep, that's the point - it's to discourage devs from checking in failing code (because then they'll be swarmed by annoyed coworkers). It's fairly common to see developer A make a breaking change to some low-level library and then see developer B push a rollback of A's changes a few minutes later (with or without A's permission).
- sparsely 5y ago
  If that's fairly common it doesn't seem like a great setup? Why not automatically run the tests beforehand? And presumably there is no need for a staging env, since your code is deployed to production as soon as it has passed tests.
  - Jensson 5y ago
    At Google your tests are automatically run beforehand, but not all tests of entire Google are run for your commit beforehand. Sometimes you break others code with your change. Edit: Just to clarify, it isn't ok to break downstream projects, if you do the change gets rolled back almost immediately. And you can run all tests for the change before submitting, but it isn't default since it is expensive for many core projects to run so many tests.
  - dboreham 5y ago
    Tests were run beforehand. Just not the right test.
whynotmaybe 5y ago
Maybe have a look at this https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
- sparsely 5y ago
  This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in (their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally?)
  - UK-Al05 5y ago
    You answered the question. You run as many tests as you can locally. Sometimes you can't, and the build goes red and you fix it with another commit.
    - pc86 5y ago
      Any workflow that involves breaking master for everyone seems broken at some level. Not saying I have a better solution off the top of my head, but "just fix it with another commit" is a big red flag IME.
      - UK-Al05 5y ago
        A broken build is meant to be everybody helps fix it situation.
        pc86 5y ago
        I'm questioning the logic of having a workflow with a not-uncommon case of "this is on fire now everyone stop what they're doing and help me fix it" which is exactly what you'd have here.
      - mjr00 5y ago
        Even if you really wanted to have it be trunk-only, I don't know why you wouldn't make everyone push to a feature branch, then have automation for running tests and merging after they pass. Plus, where's the code review in this process? Even if your team is all amazing developers somehow, it's insecure to have a standard process where developers are pushing unreviewed code directly to production. Fundamentally this all seems like a misreading of trunk-based development, though. The whole idea was to get away from old Subversion-style branching, where there would be long-lived branches running for sometimes several month. If you were a company that moved from svn -> git, trunk-based development was a way of communicating that branches were cheap and disposable, and merging was quick and easy.
stepanhruda 5y ago
The latter
- sparsely 5y ago
  The replies seem to suggest that there are a mix of interpretations, it's very confusing.
nindalf 5y ago
I can’t speak for all companies but at the place I worked at, there was a monorepo. You’d create a small, self contained change off the main branch and put it up for review. All such proposed changes would have tests run on them, so the reviewer could get a sense of the quality of changes. “Looks good, please fix that test” was a comment I’ve seen more than once. After approval, it’ll land on main and be in prod within an hour or two. For larger features, these changes could be stacked in a list. After each change in the list had been approved, they’d be landed on main as an all or nothing.
deepGem 5y ago
I worked on a Tensorflow feature in 2018. There was no branching involved. Fork the main repo, build the feature on your child repo, make sure all unit tests pass and then send a pull request to the main/master of the parent repo. Typically someone reviews the code, you incorporate code review comments, pass all unit tests, CI-CD pass, PR approved. That's it. Your code is in the next production cycle. So yes, you work locally on a fork of the repo but not the main/master repo. I'd surprised if all devs have access to push to main/master. I think having branches leads to a lot of merging issues. Because technically, the branch will then be used by multiple devs. So it's like dealing with multiple masters, kind of. Personally, I prefer the TF approach. Oh I forgot to mention, the release tags are branches I think, perhaps read only branches.
- UK-Al05 5y ago
  That's branching. Trunk is when everyone direct push access to trunk.
- Traster 5y ago
  How would you describe the difference between branches and forks? Functionally I can create a new branch, do my changes, get tests passing and PR from there, or I can fork master, do my changes, get tests passing and PR.
  - deepGem 5y ago
    Yes technically this is a branch, but like a frictionless branch. You don't have to name a branch for instance. You don't have to worry about branch deletion, even though now this is all automated. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-the-automatic-deletion-of-branches https://docs.github.com/en/repositories/configuring-branches... A fork is still a lot less friction. Otherwise, technically yes it is a branch.
    - Traster 5y ago
      Ah right, generally I quite like having branch names because I can name the brach aligned to the jira ticket that it's associated with, I'm not a big fan of jira, but atleast it documents the feature request etc. And also you can track multiple different features in flight at once (I know it's not ideal, but sometimes you're doing several different things that need to be merged in order etc)
barrkel 5y ago
Every commit is code reviewed separately and merged to master after review + automated test gatekeeping as necessary. Additional testing may occur downstream post-merge which may cause your commit to rolled back automatically. Time to deployment into production depends on how those deployment pipelines are built, could be minutes to days before it lands. It's very unusual to merge more than one commit to master at a time. You can think of it as a branch and merge approach, but the set of changes is small - a 100-line diff would be a large change (automated changes and deleting unused code excepted). The process and tooling optimizes for small changes. Refactoring is done incrementally. Big changes are gated with flags so they can be built incrementally and rolled out incrementally and turned off at the first sign of trouble.

science4sail 5y ago

> The first seems like it would be very frustrating if code with failing tests if pushed with any frequency, but seems to be literally what the phase "work on main" means. Yep, that's the point - it's to discourage devs from checking in failing code (because then they'll be swarmed by annoyed coworkers). It's fairly common to see developer A make a breaking change to some low-level library and then see developer B push a rollback of A's changes a few minutes later (with or without A's permission).

sparsely 5y ago
If that's fairly common it doesn't seem like a great setup? Why not automatically run the tests beforehand? And presumably there is no need for a staging env, since your code is deployed to production as soon as it has passed tests.
- Jensson 5y ago
  At Google your tests are automatically run beforehand, but not all tests of entire Google are run for your commit beforehand. Sometimes you break others code with your change. Edit: Just to clarify, it isn't ok to break downstream projects, if you do the change gets rolled back almost immediately. And you can run all tests for the change before submitting, but it isn't default since it is expensive for many core projects to run so many tests.
- dboreham 5y ago
  Tests were run beforehand. Just not the right test.

whynotmaybe 5y ago

Maybe have a look at this https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/

sparsely 5y ago
This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in (their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally?)
- UK-Al05 5y ago
  You answered the question. You run as many tests as you can locally. Sometimes you can't, and the build goes red and you fix it with another commit.
  - pc86 5y ago
    Any workflow that involves breaking master for everyone seems broken at some level. Not saying I have a better solution off the top of my head, but "just fix it with another commit" is a big red flag IME.
    - UK-Al05 5y ago
      A broken build is meant to be everybody helps fix it situation.
      - pc86 5y ago
        I'm questioning the logic of having a workflow with a not-uncommon case of "this is on fire now everyone stop what they're doing and help me fix it" which is exactly what you'd have here.
    - mjr00 5y ago
      Even if you really wanted to have it be trunk-only, I don't know why you wouldn't make everyone push to a feature branch, then have automation for running tests and merging after they pass. Plus, where's the code review in this process? Even if your team is all amazing developers somehow, it's insecure to have a standard process where developers are pushing unreviewed code directly to production. Fundamentally this all seems like a misreading of trunk-based development, though. The whole idea was to get away from old Subversion-style branching, where there would be long-lived branches running for sometimes several month. If you were a company that moved from svn -> git, trunk-based development was a way of communicating that branches were cheap and disposable, and merging was quick and easy.

stepanhruda 5y ago

The latter

sparsely 5y ago
The replies seem to suggest that there are a mix of interpretations, it's very confusing.

nindalf 5y ago

I can’t speak for all companies but at the place I worked at, there was a monorepo. You’d create a small, self contained change off the main branch and put it up for review. All such proposed changes would have tests run on them, so the reviewer could get a sense of the quality of changes. “Looks good, please fix that test” was a comment I’ve seen more than once. After approval, it’ll land on main and be in prod within an hour or two. For larger features, these changes could be stacked in a list. After each change in the list had been approved, they’d be landed on main as an all or nothing.

deepGem 5y ago

I worked on a Tensorflow feature in 2018. There was no branching involved. Fork the main repo, build the feature on your child repo, make sure all unit tests pass and then send a pull request to the main/master of the parent repo. Typically someone reviews the code, you incorporate code review comments, pass all unit tests, CI-CD pass, PR approved. That's it. Your code is in the next production cycle. So yes, you work locally on a fork of the repo but not the main/master repo. I'd surprised if all devs have access to push to main/master. I think having branches leads to a lot of merging issues. Because technically, the branch will then be used by multiple devs. So it's like dealing with multiple masters, kind of. Personally, I prefer the TF approach. Oh I forgot to mention, the release tags are branches I think, perhaps read only branches.

UK-Al05 5y ago
That's branching. Trunk is when everyone direct push access to trunk.
Traster 5y ago
How would you describe the difference between branches and forks? Functionally I can create a new branch, do my changes, get tests passing and PR from there, or I can fork master, do my changes, get tests passing and PR.
- deepGem 5y ago
  Yes technically this is a branch, but like a frictionless branch. You don't have to name a branch for instance. You don't have to worry about branch deletion, even though now this is all automated. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-the-automatic-deletion-of-branches https://docs.github.com/en/repositories/configuring-branches... A fork is still a lot less friction. Otherwise, technically yes it is a branch.
  - Traster 5y ago
    Ah right, generally I quite like having branch names because I can name the brach aligned to the jira ticket that it's associated with, I'm not a big fan of jira, but atleast it documents the feature request etc. And also you can track multiple different features in flight at once (I know it's not ideal, but sometimes you're doing several different things that need to be merged in order etc)

barrkel 5y ago

Every commit is code reviewed separately and merged to master after review + automated test gatekeeping as necessary. Additional testing may occur downstream post-merge which may cause your commit to rolled back automatically. Time to deployment into production depends on how those deployment pipelines are built, could be minutes to days before it lands. It's very unusual to merge more than one commit to master at a time. You can think of it as a branch and merge approach, but the set of changes is small - a 100-line diff would be a large change (automated changes and deleting unused code excepted). The process and tooling optimizes for small changes. Refactoring is done incrementally. Big changes are gated with flags so they can be built incrementally and rolled out incrementally and turned off at the first sign of trouble.