3 ms·
I was doing this a year ago. Now I'm redoing it. In my case, what I missed is that if the app is complex enough you should treat the deployer like a separate
by __MatrixMan__ 4y ago
I was doing this a year ago. Now I'm redoing it. In my case, what I missed is that if the app is complex enough you should treat the deployer like a separate product.
Different teams might want to use it for different things, deploy different versions with it, etc. So it should be in a separate repo with its own tests and its own version string. Otherwise iterating on it is hell because you're doing so in a space that's ergonomic for app development, not deployer-tool development.
That way when your deploy target changes (goodbye helm, hello custom k8s operator), your users can keep using the stable deployer version while you work on the new one.
Following that, switching between the old way and the new way becomes an atomic action, which makes it much easier to triage issues of the "it worked with the old way but breaks with the new way" sort.
Or at least... I hope that's what I missed. Because if not I'll be reredoing it next year.
- lamontcg 4y agoThat is just the next iteration on the "fake it until you automate it" path. And it can actually be a mistake to try to jump from zero directly to fully automated nirvana.
- __MatrixMan__ 4y agoAgreed. I tried to jump too early. More faking it for longer would've been faster in the long run.
- 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).