
Show HN: Comfygure – A small CLI to manage application configurations - Kmaschta
https://marmelab.com/blog/2019/05/28/releasing-comfygure-1-0.html
======
founderling
I have the feeling that most developers these days suffer from too much
tooling in every area. And would be 2 to 10 times more productive without it.

Most friends that I watch doing their deployment would be way more productive
by simply using rsync for file changes and raw database queries when the DB
needs a change.

~~~
mjlee
While that's true for a single dev, I think that quickly falls apart at scale.

The raw DB queries will invariably exist on someone's hard drive/in their head
and be lost forever when they leave the team.

The rsync for file changes will result in developers stopping to ask each
other "did this get rolled out yet?" multiple times a day.

~~~
founderling
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.

~~~
mjlee
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?

~~~
founderling
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?

~~~
dieblur
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.

~~~
founderling
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.

~~~
philipov
Not if they've never done it before.

------
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?

~~~
jalons
Hashicorp Vault hits most (all?) of these points

~~~
coder006
Vault is for secret management. If you are just looking at a key value based
store or a service discovery tool, you might want to have a look at consul by
Hashicorp.

------
seiferteric
I just wish there was more of a standard for for configuration files. Aren't
all config files at some level going to be tree like structures? I know it is
impossible for everyone to agree on one format, like yaml vs json, vs xml etc.
but maybe there could be a common library and standard that could allow each
application to load it's configuration from any of these types of files? That
way if one organization or distro or whatever wanted to all use Yaml (for
example) for all of their config, they could do that.

~~~
stephenr
IMO most configuration should just be environment variables. How you get them
there is up to you, but exporting env vars from a config file shouldn't be a
super hard task.

Having said that, if your organisation _chooses_ to use YAML, personally a
better choice would be to just burn the place to the ground.

------
rawoke083600
Hmm props to getting this out, but my way is has always been "bash is good
enough" ja its not perfect a d feature rich but gets you 80% there and most
linux based coders knows enough bash. I hate learning a new "language" just to
deploy code or servers. Guess im just too old :)

~~~
Kmaschta
Thanks! Bash is just fine, and if you don't need anything else to share
configs with your team, it's totally fine :)

We built this tool because we had a need (everything is explained in the blog
post)

------
zmmmmm
Does it have any features to handle inheritance / composition of
configurations?

We usually have a slew of different environments that are mostly the same
except for one or two parameters. I would like to find a solution that has the
ability to control common parameters in one place without having to code the
inheritance into every language / setting where the config is accessed.

In general it seems like simply storing your config in JSON or YAML and
putting it in git provides most of the features of many config solutions and
the overhead of deploying something separate to handle it rarely justifies the
marginal benefit from that.

~~~
canterburry
I didn't want to jump in with this earlier since comfy is the main topic here
but [https://configrd.io](https://configrd.io) will do the inheritance you are
asking about. It's not cli but also has an API, handles secrets and deploys on
prem.

~~~
zmmmmm
thanks! actually looks really cool, love the integrated support for storing
encrypted secrets (even if not supporting many providers yet). Will explore it
more.

------
mxuribe
I love the really cute name!

~~~
Kmaschta
Thanks!

------
harrylepotter
see also: [https://zookeeper.apache.org/](https://zookeeper.apache.org/)

