We initially thought to migrate versions from staging to production with a sort of composition, but we didn't implement that because there was a high risk of mixing credentials between environments.
That said, you can easily copy a config from one env to another and update that new config in no time.
comfy get env1 > tmp.json;
comfy setall env2 tmp.json;
comfy set env2 <key> <value>
Comfy was created because we used environment variables on multiple servers, for many environments (prod, staging, demo, dev, etc), deployed by a few developers.
The purpose of the tool is to help developers share their config and keep sync with the rest of the team.
But I agree, if it's overkill if you don't need it!
How does comfy handle devs who wish to have some personalization of their local config but otherwise get the latest version of the the dev environment?
Comfy is a store of configurations for deployed environment. It's not recommended to store you local config into comfy, but you could.
If you do so, you have a system of tags. A config version can be tagged and the tag moved.
So, the integration environment can retrieve the config with the tag 'integration', say.
And you can retrieve the latest.
Local: comfy get development
Integration: comfy get development -t integration
Change the integration tag to the latest version :
1. Get the latest config hash with `comfy log development`
2. Set the tag integration to the latest `comfy tag move development integration <hash>`
Feature flags are a good example. One developer A enable a feature and deploy its version on integation.
Two days after, developer B deploys its version, but isn't aware that A deployed with the new feature enabled, so the feature is disabled with its deployment on integration.
Ideally, developers should use a centralized configuration management to no suppress each other configs.
That's why we use Jenkins or the Atlassian suite for example. But it's heavy to install and maintain sometimes.
Write a LOT of unit tests, a good bunch of integration tests and enough end-to-end tests.
You'll be more confident in refactoring and with your developer experience in general.