How to Deploy Web Projects
By web environment we understand not just a source code repository, but also the server configuration, the programming language version, database design, etc.
In web development we usually differentiate 3 types of environments:
- development
- staging
- production
The development environment is that place where you create your code, adding new features to your web project and fixing bugs. This environment should mirror the production environment, but with smaller data: fewer database rows, fewer data files (for ex. user uploaded files), because with such environment is much faster to work with than by fully mirroring the production environment.
With small teams it’s usually fine to have a common development environment, but as the team grows you should adopt a different strategy. In the case of large teams it’s usually better to set up a development environment for every team member, because it’s much less likely to hit conflicts, but keep in mind to also set up a shared repository where developers can check out the working project.
It’s good to have a staging environment, because when new features are added to your web project the need for testing those features is essential. This environment usually sits on the production server. The main idea is that the outcome of the test results against new features are not the same on the development server, because we don’t use the same dataset as the production environment has. This is what the staging does. It tests the features against the production dataset, but these features are not yet available to end users, this is the reason that it’s a good idea to configure this environment on the same server where the production resides.
The final stage of deployment is the production environment. This environment is visible to end users.
It is important to differentiate these environments. Development with small data sets is fast enough to make changes rapidly. This is where you fix bugs and test most of the projects functionality. The staging is important, because you can test how the new code is behaving against the actual production dataset without the knowledge of end users. If everything goes well, then the code is copied to the production environment.
The staging and the actual deployment (copying the code from staging to production) can be performed automatically by build scripts. You can write scripts to test the new code against different testing methods and data. If this is successfull then perform the deployment.
If you enjoyed this article then help spread the word and please follow us on Twitter or subscribe to our RSS feed.
Subscribe to our RSS feedFollow us on Twitter