They never mention the little details in articles like this, like the fact that TBD relies entirely on CI. So what does that mean?
- CI requires an automation tool to run a test suite. If you don't have one yet, you need to set one up (and, you know, have a suite of tests to run). hand-waves the idea that the test suite is perfect
- If you don't have Pull Requests to gate the test suite before merge to trunk, the tests have to be done pre-merge. But that means it has to run on your laptop, and maybe there's too many tests. So you can do 'fake' Pull Requests, by keeping a CI server with one copy of your repo, and if the tests pass, pushing that copy or change to the 'real' repo.
- Even if you do have Pull Requests, or Fake Pull Requests, and a person has to approve them before merge (a good idea), you can still end up with a PR stuck in pending-approval state for eternity. And every time a change hits the trunk, the PR needs to be rebased, retested, and possibly bugs fixed. This means the equivalent of a branch being open for a long time - the whole reason not to use feature branches.
- Therefore, assuming you have a test suite, and a CI server, you must only merge very small changes, quickly. Not only must the change be small, you must have review & approval constantly. Or throw out the review/approval step. Or only do it once a day, which goes back towards the long-lived branches that we're trying to avoid.
- Of course with all this fast merging, it's increasingly likely you will introduce a bug, because no testing is perfect. So you have to also back out changes quickly. But you still won't always catch them quickly.
- With all these changes and reverts happening all the time, the trunk is constantly changing underneath everybody. So you have to rebase or merge constantly. If you don't, it will take you longer to refactor the changes you've just developed to work with the new changes.
- And since you can't possibly implement a complex new feature at once with only small commits, you have to use feature flags and other strategies to keep your untested new code from exploding until you think it's ready for prime time.
- As all of that is going on, you also of course need to test all this crap. So you'll need a CD system designed to constantly deploy to various environments, potentially managing many constantly changing dependencies and data sets depending on what's being pushed/tested.
- That system has at least the same complexity as the CI system, but it's infrastructure-heavy, which means you'll need to lean heavily on DevOps practices and SWE having the tools and training to manage their own deploys/infra. And we haven't even talked about versioning.
These are just some of the issues that some books cover (I think) but quaint blog posts about branching never mention. How long will it take your team(s) to implement all of that and completely change their SDLC?
- CI requires an automation tool to run a test suite. If you don't have one yet, you need to set one up (and, you know, have a suite of tests to run). hand-waves the idea that the test suite is perfect
- If you don't have Pull Requests to gate the test suite before merge to trunk, the tests have to be done pre-merge. But that means it has to run on your laptop, and maybe there's too many tests. So you can do 'fake' Pull Requests, by keeping a CI server with one copy of your repo, and if the tests pass, pushing that copy or change to the 'real' repo.
- Even if you do have Pull Requests, or Fake Pull Requests, and a person has to approve them before merge (a good idea), you can still end up with a PR stuck in pending-approval state for eternity. And every time a change hits the trunk, the PR needs to be rebased, retested, and possibly bugs fixed. This means the equivalent of a branch being open for a long time - the whole reason not to use feature branches.
- Therefore, assuming you have a test suite, and a CI server, you must only merge very small changes, quickly. Not only must the change be small, you must have review & approval constantly. Or throw out the review/approval step. Or only do it once a day, which goes back towards the long-lived branches that we're trying to avoid.
- Of course with all this fast merging, it's increasingly likely you will introduce a bug, because no testing is perfect. So you have to also back out changes quickly. But you still won't always catch them quickly.
- With all these changes and reverts happening all the time, the trunk is constantly changing underneath everybody. So you have to rebase or merge constantly. If you don't, it will take you longer to refactor the changes you've just developed to work with the new changes.
- And since you can't possibly implement a complex new feature at once with only small commits, you have to use feature flags and other strategies to keep your untested new code from exploding until you think it's ready for prime time.
- As all of that is going on, you also of course need to test all this crap. So you'll need a CD system designed to constantly deploy to various environments, potentially managing many constantly changing dependencies and data sets depending on what's being pushed/tested.
- That system has at least the same complexity as the CI system, but it's infrastructure-heavy, which means you'll need to lean heavily on DevOps practices and SWE having the tools and training to manage their own deploys/infra. And we haven't even talked about versioning.
These are just some of the issues that some books cover (I think) but quaint blog posts about branching never mention. How long will it take your team(s) to implement all of that and completely change their SDLC?