4 ms·
Comfy was created because we used environment variables on multiple servers, for many environments (prod, staging, demo, dev, etc), deployed by a few developers
by Kmaschta 7y ago
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!
- founderling 7y agoCan you give an example of such an environment variable?
- Kmaschta 7y agoFeature 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.
- daveFNbuck 7y agoHow 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?
- Kmaschta 7y agoComfy 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>`