4 ms·

Perhaps I can shed some light into your questions as I work on TBD since 3 years now. In our case there are no Pr's, we push to master, the test suite is trigg

Perhaps I can shed some light into your questions as I work on TBD since 3 years now. In our case there are no Pr's, we push to master, the test suite is triggered, the dev environment receives the new code. It moves to other environments if the tests pass. We release to master using a canary instance that gets only a small share of the traffic, if our metrics for success fail then we rollback and start a hotfix. Yes you can have as many branches you want in your local but in the remote there is only one.

coolgoose 1y ago
And how is that different than just doing a pr, and merging to trunk? It feels like you are just canceling a lot of pipeline tests all the time, assuming there's a cadence of 10+ pushes per day.
MichaelNolan 1y ago
> In our case there are no Pr's, we push to master Just to clarify, are you saying there is no code review where another engineer looks at your change before you merge to main? I’ve never seen a TBD project work that way. I can’t imagine how it would work for anything but the smallest teams.
- ainiriand 1y ago
  In our case we are 3 devs.
  - SenHeng 1y ago
    I have been in projects where I am the sole dev, and I still create PRs and self review them before merging. I do this because I am human and make mistakes.
Disposal8433 1y ago
> we push to master, the test suite is triggered If you have a bug due to the last commit, don't you have to write fixes all the time? How do you review the code?
- JimDabell 1y ago
  You make sure it works first. Are you opening PRs with bugs “all the time”? Why? Nothing is ever bulletproof, but bugs shouldn’t be the norm in new code.
  - ansgri 1y ago
    That requires the ability to fully test it locally, which unfortunately is uncommon in decent-sized systems.