Web Applications: Development for Production

Question

Here is my current work of my company in transferring changes from our development server to our production server:

• Files that need updating are discarded so as not to make any changes only in production (no, this should not be, but yes, it really is). Old development files are prefixed as a kind of "backup".
• The developer makes the necessary changes.
• Updated files in development are copied from this server and inserted into the appropriate place on the production server. Old production files are prefixed as a kind of "backup".

I know this is a terrible way to do something, but what is the best way to do this? My initial idea was to move all of our code into subversion. Then, when something needs to be updated, make changes to the development, transfer it to the repository, and then upgrade the production server from the repository.

Does anyone have alternatives / changes / constructive criticism? Our development team has only 6 people, and our code base is splashing ASP (a very old, terrible legacy), PHP (a little newer) and Java EE (the latest code, all applications are built as separate WARs).

Thanks in advance

edit:. To develop our Java EE applications, each developer has Glassfish v2 running on his machine. For PHP / ASP, we have a central dev server. For production, we have a server for PHP / ASP (IIS), and another for Java (Glassfish v2).

Answer 1

As said, source control is defined. This is a tool around which all coding and deployment should be performed.

You can also use a deployment tool like Capistrano or a build tool like Phing .

I use Capistrano to deploy our PHP application, and using one terminal command, it will be:

• Verify a copy of the project from the control source
• Paste in the deployment version folder
• Starting custom tasks - for example, writing symbolic links to a shared folder, performing db tasks, changing the environment variable from stage to production, etc.
• Create a symlink between the application shared folder and the doc server root

If something goes wrong, it will automatically roll back to the last good deployment. This is such a useful tool. Can't recommend it enough.

EDIT: Just realized that this is not a question only for PHP. Deployment tools will vary depending on your platform. Capistrano is great for Rails or PHP. Phing is a PHP version of Apache Ant. You can request the best tool for your chosen platform.

Answer 2

You are right, using source control (subversion, git, mercurial, etc.) will greatly simplify your life.

The following are the basic steps that must be taken when making changes to the production environment:

• Developer makes changes to the branch from the main part of the project
• When all changes are made and pass the tests, merge the changes back to the trunk
• Make a trunk tag
• Export this tag to your production environment. If something goes wrong, you can always return to the previously deployed tag.

Answer 3

Yep .... definitely need some kind of source control. Personally, I like SVN and feel that it's pretty easy to set up.

Before moving into the deep end, I thought about how your deployment strategy should work. How do you want to handle concurrent development? Do you need / need a quality assurance environment or the user you are deploying to? Sit down with the rest of the group and come up with a list of use cases and, to make sure you are on the same page, your strategy fits and that you are all on board with the solution.

Answer 4

I would say that you are on the right track. Gaining control over data sources, subversion or otherwise is vital. Then use some continuous integration, such as CruiseControl, to manage direct deployments or create deployment packages. And do absolutely everything that you can, so that no changes in production occur, he really throws the key to the whole process.

Answer 5

As you said, subversion is likely to help in your case: using some version control system is fine , and subversion is working fine - and you probably don't need a decentralized system (like git / mercurial / ...).

Main advantages:

• It’s easier to share the changes made by each developer in your team.
• one central place where the " official version of the sources
• possibly a simple deployment.

Although, I would not just use svn checkout on my production server: well, it can work fine in some cases, but, especially if you sometimes modify files directly on the production server (which you definitely should not do!), You will end up run into problems (e.g. conflicts) on the production server ...

Yes, you can use svn merge in dry-run, but this is not always enough ... And there are no dry updates to update svn - and a conflict in the PHP file usually means a parsing error; and this is bad when it happens on the production server ^^

Instead, I would:

• working fine by doing svn when it's ok to do it
• once in a while (the day before deployment to production, for example), export svn and deploy the extracted application to the intermediate server
  • which means that you can test an environment that is closer to the product than your development platform.
  • and also means that nothing should go directly to production without testing in an intermediate environment!
• if everything is fine on the staging server, then deploy the same package to the production server.

Oh, and, by the way, about the deployment process, you might be interested in the answer that I give on this issue a while ago: Updating a web application without downtime

As a side element: getting started with such a process is not always easy, therefore:

• Think as much as possible before you begin; posting on SO is a good start, but be sure to discuss with your colleagues who will use this system!
• Take your time: there is probably no rush, and a couple of days of thinking is always useful ;-)
  • i.e. Think about the situations you may encounter and your use cases to make sure that the processes you put in place will work for you.

Answer 6

Capistrano is a great tool, but I find it redundant for projects without Rails. This is a good guide for deploying PHP projects in multiple environments from the repository: http://themetricsystem.rjmetrics.com/2010/02/01/simple-deploy-script-for-php-applications/