views:

77

answers:

1

Hello,

situation

We our little company with 3 people, each has a localhost webserver and most projects (previous and current) are on one PC network shared disk. We have virtual server, where some of our clients' sites and our site.

Our standard workflow is:

Coder PC → Programmer localhost → dev domain (client.company.com) 
                                        ↓
                                  live version (client.com)

It often happens, that there are two or three guys working on same projects at the same time - one is on dev version, two are on localhost.

When finished, we try to synchronize the files on dev version and ideally not to mess (thanks ILMV:]) up any files, which *knock knock * doesn't happen often.

And then one of us deploys dev version on live webserver.

question

we are looking for a way to simplify this workflow while updating websites - ideally some sort of diff uploader or VCS probably (Git/SVN/VCS/...), but we are not completely sure where to begin or what way would be ideal, therefore I ask you, fellow stackoverflowers for your experience with website / application deployment and recommended workflow.

We probably will also need to use Mac in process, so if it won't be a problem, that would be even better.

Thank you

Edit: One of the crucial parts is moving website from dev to live after any working update. Edit: I will check MaxVt's answer if no other will appear :)

+4  A: 

It is an involved question, but generally there are three major improvements you need to make to improve your processes.

Use version control

If projects are on a shared disk, I assume there's just a folder with the current state of each project. It is easy for developers to overwrite each other's changes, there's no history, and you can't be sure if a project is in a consistent state or something is currently broken.

Choose a version system and start using it. It's less important which one (of free ones - SVN is OK and more "centralized", git or mercurial are great and allow greater flexibility), but it's more important that any change, no matter how small, always goes through the version control.

Simplify promotion, deployment and rollback

There is probably a sequence of steps needed now to move from localhost to dev, and from dev to production - synchronize files, restore the database to a known state, configure server-specific settings... There may be a document describing what needs to be done, or it could be tribal knowledge. Your goal should be to begin simplifying and automating that, achieving a single command or script to do all the work needed to synchronize a server (local, dev or production) to a revision of a project in your source control.

By automating deployment, you can be sure all necessary actions are done in proper order, and you will not have mistakes in deployment that can happen even when all files are correct but some configuration or command was not run, breaking the site.

Introduce testing

How do you know that the revision you've just deployed not only compiles properly, but works as expected? For each non-trivial project, you should have tests to verify the most important functionality (login, adding stuff, producing reports, etc.) to make sure that the changes made by developers left the site operating properly.

There are testing frameworks specifically for testing web apps (Selenium comes to mind). Study them and apply them. Ideally this testing suite would be run as part of the one-liner deployment script.


Once you have done those, you've come a long way to having an orderly, predictable, and resilient development process. Your clients and your developers will thank you for that :)

MaxVT
+1 Great comment. How would you script/automate deployment in Win(local) <-> Linux(server) env.? Because, honestly, I have no idea.
Adam Kiss
If everything goes through source control, then it's Win(local) <-> source ctl, and Linux(server) <-> source ctl.On a basic level you can start with shell scripts (Windows has cygwin). Two steps that you will have are sync (synchronize all source files from source control) and build (make all necessary changes to config files, insert database data, move files around if necessary, and any other tasks).Depending on the complexity of the project and your development environment, you may want to move to a real build system (for example Phing for PHP, or make for almost any environment).
MaxVT
A build system has an overhead of installing the system itself as well as learning/configuring it to your project, but you gain better process, less "menial labor" to make the system perform the various steps you need, and better error handling.
MaxVT