4 ms·
In addition to the benefits above, by storing storing config in version control is 2 party control, presubmit linting, and easy rollbacks. I suppose the trade o
by ablatt89 2y ago
In addition to the benefits above, by storing storing config in version control is 2 party control, presubmit linting, and easy rollbacks. I suppose the trade off is slower rollouts of config and some delay time in pushing out a config but hey, there's no free lunch :-)
- daemin 2y agoNothing preventing you from building a versioned configuration system using a database or similar, especially if you build tools to actually change the configuration rather than hand editing text files.
- rockwotj 2y agoGoogle has this, IIRC it’s called CDPush
- underdeserver 2y agoCDPush does versioning, canaried rollouts of... hand edited text files.
- ablatt89 2y agoI believe CDPush still has some latency involved which would be slower than reading raw config data from a DB.
- kccqzy 2y agoCDPush does the pushing. It's not a database.
- acac10 2y agoThe key to this is machine AND human readable formats. That is why the text format of protobufs is such a good approach: - structured formats - declared schema - the parser to read the file is also a validity checker (at least for data types) There are tools that do similar with JSON but none are as simple and unobtrusive as protobuf tool chain.
- acac10 2y agoWhen SOX compliance became a thing (remember Sarbannes-Oxley?), many moons ago, I was able to send EY consultants away during their audit for Unix controls, just by showing them that all our (Autodesk Unix team) configs were in SVN, logged, with authors and full change control. The Windows team had to spend months figuring out something that was not even remotely close to control or auditability. Frankly, I just assumed that it was the std practice today and I am surprised people are still not doing it.