The problem

Before we set out to solving the problem, we should have a clear understandig of what the problem is exactly.

Published

Goal

Look at all the aspects of the problem areas.

Steps

Our problem environment looks like the image below.

On the left there are three developers, of which one is the lead developer responsible for maintaining not only his own development environment, but also the production site. The developers use GIT to submit their changes to a central place somewhere on their network or internet sites like GitHub or SourceForge.net. When a new release is due the problem arises how to safely get all the development work on the production site. But when a new developer is added to the team, this new developer isn't simply up and running after running 'git clone'.

Local environment versus production environment - settings

So let's have a look what problems we are facing. First there is the problem of the local development environment. What does a developer usually need when working on a PHP website?

  • source code with a reference to the central repository
  • local database
  • local user content

With his local working files of the source code the developer can fix bugs or create new or improved functionality. In order tot test this he/she usually needs local content stored in a database. In order to gain access to the database the developer will need a user and password that will probably differ from the ones in the production environment. Maybe there are other usernames, passwords and keys (for instance OAuth2 or ssh keys) that differ between the local and production environment.  Other settings like the release date or an indicator warning the website user 'This is the development environment!' must be present.

So the first problem is the separation of local settings versus production settings.

Local environment versus production environment - user content

Chances are that your website has user content that is not stored in the database, but on the local filesystem of the webserver. For instance a photo album with images uploaded by end users. The images stored for the photo album in the production environment could be stored on the file system. When uploading our source code using FTP we must ensure that our local test images are not uploaded, resulting in either taking up a lot of wasted storage or showing your private holiday images online.  Also the files making up the GIT environment must not be uploaded. This will waste a lot of diskspace on the production machine. 

So the second problem is making sure our local ┬┤end user content' we used for testing are not accidentally uploaded to the production environment.

Other problems

When collaborating there are other problems as well:

  • keeping database structure in sync over all instances
  • management of scheduled jobs like CRON or WinAt
  • proper testing before submitting
  • (automated) regression testing
  • etc.

These topics are not (yet) addressed in this tutorial.

 

 

 


Summary

Now we have a clear understanding of the local environment problems and why you should consider using a build script before uploading.


Tags


Copyright 2013 Martin Molema