[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.

[sametmax]

Yes. Money. You are missing that it's often missing.

[Kmaschta]

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!

[daveFNbuck]

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?

[Kmaschta]

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

[founderling]

Can you give an example of such an environment variable?

[Kmaschta]

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.

[stephenr]

I wanted to post this earlier but hit the posting limit, so, here it is, with apologies for the delay forced upon me:

Tooling is literally just tools. You can have good ones and bad ones and either use them well or use them poorly. A deployment tool like Capistrano or deploybot is a tool, but so is a shell script that runs rsync the the same way each time it's invoked.

An automated deployment process that involves either zero or minimal human work, (e.g. 'click a button' or 'push to branch X in dvcs') means you get repeatability, and with that comes reliability. How many deploys will be messed up if someone is manually running rsync, because they forgot to exclude some files/dirs, or because they had a trailing slash in a path and things got put 1 directory level too deep?

For DB migrations in particular, I think you're alluding to not using a language/framework/model based migration (e.g. `rails db:migrate`) but instead to use just plain SQL. The difference for me here is whether you're suggesting they literally run the SQL required by hand (e.g. remembering/deducing which migration is required themselves, and either running an SQL file or typing the SQL into an interactive SQL session) or just that plain SQL should be used.

I have positive and negative thoughts about framework/model generated schemas. I think having the model system automatically generate/update schemas based on the model's properties, works fine for a dev environment, but for anything like testing/staging/prod environments, I believe the "best" solution is stored SQL files (preferably in the VCS itself) that are applied automatically by a tool. Those SQL files could be generated as an SQL 'diff' after running the Model generator if you wish, or they could just as easily be hand-written queries. Either way they should be reviewed as with the rest of the code anyway, so their origin is less important than their content.

And yes, I am somewhat "biased" in this: I've written a PHP framework that (amongst other things) will perform model-generated schema changes, and I've written a shell tool (written in shell) that will automatically apply DB migrations and rollbacks from a series of `{up,down}.sql` files.

As explained above, I see the former as a development tool, and the latter as a deployment tool.