Hacker News Reader

Comment by sparsely | Hacker News Reader

> 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

* 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.

View on HN

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.

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.

> 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).

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.

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.

Tests were run beforehand. Just not the right test.

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

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?)

> This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in

No, in trunk-based development, you push to the trunk, aka master.

The difference is perhaps not that big; with TBD, you have a branch, but only on your machine, which you merge to master before pushing, whereas with the second workflow, you push your master, then merge somehow.

> their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally?

I don't understand this. Of course you can and should run all tests locally.

> No, in trunk-based development, you push to the trunk, aka master.

If you follow the ops link there are multiple diagrams where that is not the case.

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.

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.

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.

Master isn't broken for everybody though? Its just broken for those projects whose tests are broken, everybody else can still work as normal.

So unless you have a ton of dependencies you wont notice much breakages from other teams.

A broken build is meant to be everybody helps fix it situation.

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.

Tests breaking should be rare. And trunk based development requires the team working closely together. So working together isn't a adrupt thing.

One of the premises is that the minimum level of competence of the team should be above average, which is not feasible everywhere.

And

"The short-lived feature branch should only last a day or two and never diverge from the trunk enough so that a merge back is problematic. After the seal of approval from code reviewers and CI daemons, it should be merged back into the trunk. It should be deleted, as proof of convergence. The developer in question may then go ahead and make the next short-lived feature branch for the next story/task they’re doing" https://trunkbaseddevelopment.com/youre-doing-it-wrong/#dura...

This is a very git-centric view. There are other source code management systems.

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.

This is just branching, except your branch is in a different repo. You just call the branch downstream/master and your local master, instead of the more common origin/yourbranch and your local yourbranch.

For the rest the merging issues are identical. You can still have a merge conflict between downstream/master and origin/master if someone merged something conflicting into origin/master since the fork happened.

What you say is certainly true, but there are still meaningful differences: named branches give you the option to push them before merging as an informal remote backup (good) switch to a different named branch (neutral) and let the old one grow stale (very bad)

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.

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...

A fork is still a lot less friction. Otherwise, technically yes it is a branch.

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)

That's branching. Trunk is when everyone direct push access to trunk.

The latter

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

Reply on news.ycombinator.com