cdesmarais 49673 (10/29/2014)

---

Grant Fritchey (10/28/2014)

---

cdesmarais 49673 (10/27/2014)

---

It's not magic. It's also not a free lunch. There are tradeoffs even beyond the extra up front work of TDD and automation. CI is poor at vetting up front architecture. Deploying on a "good enough for my current cases" data store or schema design has bitten more then one team I've worked with. The problem is that CI conceptually focuses on code, which is trivially replaceable. Once data is persisted, there is nothing trivial about changing it. Yay, job security, but I'd rather it got done right the first time. That's why, like others, I am in favor of a hybrid model. We deploy code like objects through a decentralized CI pipeline, where individual teams manage their own procs etc all the way to production, but the database engineering team still vets schema changes and non-trivial data updates and manages a seperate deployment pipeline for those. It's not perfect. The dev teams experience friction getting their changes through, and it's not always obvious to them how to coordinate their code changes in their pipeline with the schema changes in the one they don't own, but hopefully it mostly works.

That's actually really interesting. I'd love to hear more about how it works. Do you have a document you can share?

Unfortunately I don't. When I crawl out from under our 2014 upgrade, I may write something up. Conceptually each team has their own git repo which holds code objects which they are solely responsible for. Their process deploys those as part of their CI/CD pipeline. Part of that pipeline also syncs their objects into a master repo owned by the database engineering team. The master repo also holds all the shared objects, and we have our own manually triggered pipeline to deploy from that into the different environments (CI, QA. Prod)