Show HN: Comfygure – A small CLI to manage application configurations
1–10 of 33 posts
Re: Show HN: Comfygure – A small CLI to manage application configurations
#2I love the really cute name!
Re: Show HN: Comfygure – A small CLI to manage application configurations
#3I 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.
Re: Show HN: Comfygure – A small CLI to manage application configurations
#4I 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.
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.
Re: Show HN: Comfygure – A small CLI to manage application configurations
#5I 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.
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.
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.
Re: Show HN: Comfygure – A small CLI to manage application configurations
#6I love the really cute name!
Thanks!
Re: Show HN: Comfygure – A small CLI to manage application configurations
#7Earlier quoted context omitted.
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.
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?
Re: Show HN: Comfygure – A small CLI to manage application configurations
#8Earlier quoted context omitted.
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.
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!
Re: Show HN: Comfygure – A small CLI to manage application configurations
#9Earlier 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!
Can you give an example of such an environment variable?
Re: Show HN: Comfygure – A small CLI to manage application configurations
#10Earlier 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?
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?