Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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


In our case we are 3 devs.


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.


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


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.


That requires the ability to fully test it locally, which unfortunately is uncommon in decent-sized systems.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: