Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Comfygure – A small CLI to manage application configurations

marmelab.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Show HN: Comfygure – A small CLI to manage application configurations

#11

Post by Kmaschta »

founderling wrote: post #9
Kmaschta wrote: post #8

Earlier quoted context omitted.

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!

Can you give an example of such an environment variable?

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.

Re: Show HN: Comfygure – A small CLI to manage application configurations

#12

Post by dieblur »

founderling wrote: post #10
mjlee wrote: post #7

Earlier quoted context omitted.

I can see that happening as a result of some other requirement, but I can't work out why you'd purposefully structure a team so that only one team member can push to production. To me, the downsides (single point of failure) outweigh the benefits (ease of deployment.) Is there something I'm missing?

Well, each team member has their own set of skills. Say ... Joe. Joe is good at looking at some mockup and turning it into html+css code. So somewhere in the development process, Joe has an important role. But why should Joe be able to push something to production?

I think the argument isn't so much that "everyone needs to be able to push to production" as much as "more than one person should be able to push to production". Bus factor is an important variable.

Re: Show HN: Comfygure – A small CLI to manage application configurations

#13

Post by founderling »

dieblur wrote: post #12
founderling wrote: post #10

Earlier quoted context omitted.

Well, each team member has their own set of skills. Say ... Joe. Joe is good at looking at some mockup and turning it into html+css code. So somewhere in the development process, Joe has an important role. But why should Joe be able to push something to production?

I think the argument isn't so much that "everyone needs to be able to push to production" as much as "more than one person should be able to push to production". Bus factor is an important variable.

That's like saying a company needs two CEOs because of bus factor.

Somebody else can take over the role of being responsible for pushing to production any time.

Re: Show HN: Comfygure – A small CLI to manage application configurations

#14

Post by daveFNbuck »

Kmaschta wrote: post #8
founderling wrote: post #5

Earlier quoted context omitted.

Could be. I only know environments where every project has exactly one team member who can push to production. Usually the version control happens in git. And the person who can push to production is also the person in charge of the master branch. I always structure teams that way. So I cannot speak for other structures.

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?

Re: Show HN: Comfygure – A small CLI to manage application configurations

#15

Post by Kmaschta »

daveFNbuck wrote: post #14
Kmaschta wrote: post #8

Earlier quoted context omitted.

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 `

Re: Show HN: Comfygure – A small CLI to manage application configurations

#16

Post by philipov »

founderling wrote: post #13
dieblur wrote: post #12

Earlier quoted context omitted.

I think the argument isn't so much that "everyone needs to be able to push to production" as much as "more than one person should be able to push to production". Bus factor is an important variable.

That's like saying a company needs two CEOs because of bus factor. Somebody else can take over the role of being responsible for pushing to production any time.

Not if they've never done it before.

Re: Show HN: Comfygure – A small CLI to manage application configurations

#17

Post by bruceboughton »

At my work, we use an internal config store developed by another team for app config management, versioning and audit history.

It’s a bit flaky so we’ve been looking to replace it but don’t want to spend the company’s money building it. We’ve been looking but have not really found anything OSS.

We’re looking for:

- store text/binary documents

- full audit history of document versions

- get/put like api to retrieve/replace documents

- GUI to explore history/documents

- easily deplorable on Windows (ideally without an app server)

Anyone got any (more) suggestions?

Re: Show HN: Comfygure – A small CLI to manage application configurations

#18

Post by jalons »

bruceboughton wrote: post #17

At my work, we use an internal config store developed by another team for app config management, versioning and audit history. It’s a bit flaky so we’ve been looking to replace it but don’t want to spend the company’s money building it. We’ve been looking but have not really found anything OSS. We’re looking for: - store text/binary documents - full audit history of document versions - get/put like api to retrieve/re…

Hashicorp Vault hits most (all?) of these points

Re: Show HN: Comfygure – A small CLI to manage application configurations

#19

Post by ksajadi »

bruceboughton wrote: post #17

At my work, we use an internal config store developed by another team for app config management, versioning and audit history. It’s a bit flaky so we’ve been looking to replace it but don’t want to spend the company’s money building it. We’ve been looking but have not really found anything OSS. We’re looking for: - store text/binary documents - full audit history of document versions - get/put like api to retrieve/re…

autocorrect strikes again: “deplorable on Windows”. Loved it!

Re: Show HN: Comfygure – A small CLI to manage application configurations

#20

Post by sametmax »

mjlee wrote: post #7
founderling wrote: post #5

Earlier quoted context omitted.

Could be. I only know environments where every project has exactly one team member who can push to production. Usually the version control happens in git. And the person who can push to production is also the person in charge of the master branch. I always structure teams that way. So I cannot speak for other structures.

I can see that happening as a result of some other requirement, but I can't work out why you'd purposefully structure a team so that only one team member can push to production. To me, the downsides (single point of failure) outweigh the benefits (ease of deployment.) Is there something I'm missing?

Yes. Money. You are missing that it's often missing.
Post reply on HN