31–38 of 38 posts
How is this different from/better than Stack Exchange's blackbox[0] which doesn't require a third-party service (just plain-ole gpg) and is written in bash? [0] https://github.com/StackExchange/blackbox P.S.: I think the image looks aesthetically pleasing, but why is it there? It's a scaled-down 1,600x680px image that costs me 140KB and doesn't add anything to the article; what's worse is that it's not even a nice ba…
What year is it?
Earlier quoted context omitted.
> If you want to run local environment you can simply create your own configuration. Externalizing config forces you to cleanly handle local environments as well. There's nothing special about them. I generally recommend having an env.example file listing out required environment variables with sensible local defaults. This eases onboarding a new developer or even an existing developer on a new machine. > I don't rea…
I'm sorry but I really don't understand how having env.production.toml commited in the same repository as code makes anything that you said impossible/more difficult. I can always grab the build from production and run it locally with the modified config.
Which production env? Which datacenter? Which database cluster? &c
The deployment should take care of generating configs, they shouldn't be hardcoded or stored anywhere imho.
Earlier quoted context omitted.
The linked part about config makes sense. It's a specific instance of a general concept that shows up in hardware and software engineering. That's that things that reusable things that don't change should be separated from those that change often. In this case, we have code and [configuration] data. The data can and will vary considerably while reusing the same code. They should be separate so data changes don't requ…
> data can and will vary considerably while reusing the same code. This is the complete opposite of my experience. We deploy new code to production 10 times per day and change configuration a couple of times per month. What do you keep in configuration that changes this often?
Earlier quoted context omitted.
I'm sorry but I really don't understand how having env.production.toml commited in the same repository as code makes anything that you said impossible/more difficult. I can always grab the build from production and run it locally with the modified config.
> env.production.toml Which production env? Which datacenter? Which database cluster? &c The deployment should take care of generating configs, they shouldn't be hardcoded or stored anywhere imho.
Sure deployment can generate configs but it has to take it from somwhere. So you need a database preferably with versioning and encryption. It's also nice if you know which settings are used in specific builds so you can go back and debug past production issues.
Of course for larger teams and deployments it makes sense to develop and maintain this infrastructure. But since we already have git, why not just use it.
Earlier quoted context omitted.
> data can and will vary considerably while reusing the same code. This is the complete opposite of my experience. We deploy new code to production 10 times per day and change configuration a couple of times per month. What do you keep in configuration that changes this often?
Well, it depends on internal projects vs external ones. Internal ones might work as you described. External ones will have many more deployments than code changes for a given module.
How is this different from/better than Stack Exchange's blackbox[0] which doesn't require a third-party service (just plain-ole gpg) and is written in bash? [0] https://github.com/StackExchange/blackbox P.S.: I think the image looks aesthetically pleasing, but why is it there? It's a scaled-down 1,600x680px image that costs me 140KB and doesn't add anything to the article; what's worse is that it's not even a nice ba…
> image that costs me 140KB What year is it?
Earlier quoted context omitted.
I keep hearing this "violation of Twelve-Factor" statement. The Twelve-Factor Methodology is a sensible set of guidelines/defaults for building a modern app, as written by Heroku. Don't blindly follow it As It Was Written without thinking. Seriously, do what works. Use your brain. Using this statement as an argument against other methods is sending the wrong message.
The linked part about config makes sense. It's a specific instance of a general concept that shows up in hardware and software engineering. That's that things that reusable things that don't change should be separated from those that change often. In this case, we have code and [configuration] data. The data can and will vary considerably while reusing the same code. They should be separate so data changes don't requ…