Continued Thoughts on a Websites’ Environment

Yesterday I started to think and look about developing deploying a (typical, simple, PHP based) website and how to manage configuration under version control.

After taking some sleep over night the open ends became more clear, also some different approaches:

Environment and Questions

Yesterdays post did not cover how to set the environment. How do we tell the system in which environment it is in? In the Syfony2 example it is set in the app-script (I have no better name for that, Front-Controller sounds bloated to me for that bootstrap like app.php script). In Heroku it is with environment variables. So on both cases there is some kind of pre-configuration. In my understanding with the git-based website, no such pre-made configuration exists that specificies the environment to allow configuration differences per environment / host then.

Is this with some magic configuration, meta configuration, uber configuration? I doubt so. The building idea (see below) came to mind because of that.

Also I asked myself how to deal with the problems of cross-platform compatibility? Do I want to do large setups on the target system to be able to deploy? No I do not want to. Not in this case. I want something I can usefully work on step-by-step, ideally extend it as needed, grow slowly. This is not yet using Puppet, Chef or else to scratch an enterprise itch. This is small, and I want it git based, probably php based. And small. A nice and simple solution for a low-level common problem.

And even if other tools are used, similar problems need to be solved: How to organize the configuration differences? And similar. Probably it’s worth to look into Chef and Puppet to find out how they organize environments and the sensitive data. They should have solved that in a concise way so worth to gain some knowledge from there.

Building

If there is a build process before deployment it could also create the target environment specific configuration. Secrets/Sensitive information can be asked for while building (and cached for comfort but taken out of the repository).

This can also solve the problem to make scripts / processes run on different platforms.

A downside is, that once you build for the production environment, the local development environment does not work any longer. It would require an additional build for the local environment again. However, this looks feasible as a build is always automated.

A plus could be that it is easier to (manually) test if the configuration management works. This makes (the first) deployment more predictable, more safe.

Another plus is, that it is more visible how to come from the bare (initial) configuration to the current one. It’s more clear which files to put under git and which not.

I have the feeling that something like staging is more easy, too. Actually from the “production only” site to development / production differentiation, this already is some kind of a staging process.

As building is another concept that could be borrowed from the software development world, there is to look into Make or Ant. I heard there is something like targets. Lets see. Maybe a build system is already all I need.

I hope I find the time tomorrow to look more into this, especially a short review on Puppet or Chef and Make or Ant and maybe some of the other players in that league about environments/targets and sensitive data.

This entry was posted in Pressed and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s