3 ms·
> So it should be in a separate repo If it's in the same repo, that means all of the features of the deployer can match the deployed code automatically - the d
by drewcoo 4y ago
> So it should be in a separate repo
If it's in the same repo, that means all of the features of the deployer can match the deployed code automatically - the deployer is made for and tested for that version.
With different repos, you add complexity. Now you have to support deploying multiple versions so there are more code paths and there's version checking etc. And more complexity also means you need more tests.
- bobkazamakis 4y agoif it's not in the same repo, it means that the deployer can be updated and rolled out independently, and scale with its own resources. if it's in the same repo, you add complexity -- now I have to ensure my deployment of two unrelated code bases don't collide, there's more cross-team conflicts, and I have to clone down a 200gb repo.
- __MatrixMan__ 4y agoRight, and not just one 200gb repo. If I want to do a git bisect of the app while holding the deployer constant I have to wrangle at least two of them.
- __MatrixMan__ 4y agoHaving everything together in the same repo is great if - you don't care about tests that span multiple versions of the app (e.g. patterns of usage around database upgrades) - you don't care about git bisect sessions that evaluate a new test against old versions of the app - you never want to try the new app on the old infra or the old app on the new infra - you're not worried about tests written by people not on your team whose failures indicate scenarios that don't require action on your part (but might require action on theirs).