Situations with a slow deployment process has been a big motivator for building Config.ly -- and I've seen it happen at companies with medium-sized eng teams (taking hours to swap values during incident fires), and I know it's a problem _all_ iOS developers have due to the app store deploy process.
I also think there's other value here... For instance having a UI means non-technical folks can update it. A lot of my time as an engineer has been spent making copy tweaks (I've felt existing CMS products were too heavy-weight and difficult to plugin).
Also, having turn-key libraries mean you don't have to copy/paste hardcoded values among many clients (or store on the server build an API for _every_ constant). I'm a big fan of DRY.
An instance of an app (process, service, whatever) doesn't need to know that it's "dev", "test", "prod". Just have it look for "the database" and change the /etc/hosts (or equiv) as needed.
My impression is that istio (?) is supposed to formalize this approach. That'd be nice.
I'm so done having this conversation with teammates. Yet another reenactment of the "why use version control" war. There's always some stubborn refusal to join the third millennium. Because reasons. It's too complicated. No one knows how to do that. It's hard to debug. Whatever.
Every new cohort believes they're the first to invent configuration management.
I could be wrong, but I think some folks would want their other clients -- even their server -- retrieving that value from that one single source. So when you roll an Android app, you'd also want to implement HTTP + caching... And basically you're on the path to building your own Configly.
In my GraphQL api I have a resolver called appConfig. That enables me to fetch the config I need for a screen in the same request as the data and to reuse any caching/offline/http logic the app already has. Zero added latency. No service can beat that, but then it‘s also just me editing postgres to change the config.
It's nice to be able to push things into the system while it's running without hopping through all the hoops of qa, staging, etc. We then usually move it into the applications base configs in the app repo if it's going to stick around for more than a day or two to keep things tidy.
There's nothing wrong with a service to push config into a system at run-time, and you don't have to throwaway the benefits of the git history.
Who has access to each client's database? Is it audited? Is it encrypted at rest? I'm sure it is, but Config.ly would be wise to add this information to avoid fears.
Also you can store encrypted secrets in Git just fine, there are a number of methods to do so very safely.
> Who has access to each client's database? Is it audited? Is it encrypted at rest? I'm sure it is, but Config.ly would be wise to add this information to avoid fears.
This is great feedback, thank you.
https://docs.travis-ci.com/user/environment-variables/#defin...
You’re able to guard secretes as need, but keep the audit-ability of version control.
You set those on deployment so your engineering team never see production secrets