What is deployment?
Deployment involves moving the web site from one environment to another. In most cases, this refers to publishing the web site from the development server to a production (live) server. However, deployment might also involve multiple stages (development, staging & production).
What types of CMS deployment are available?
CMS deployments follow a few different patterns:
- Baked vs. Fried
- Coupled vs. Decoupled
- Single server vs. Multi-server
- Single stage vs. Multi-stage
- One-way vs. Two-way
Baked vs. Fried Deployments
In a restaurant, orders for baked foods (cakes, breads, cookies) rely on the item being pre-made in advance. Whereas orders for fried foods (eggs, fish, steak) are made to order just before being served.
Similarly, a “baked deployment” is pre-made before it is delivered to the production server. Once deployed, the web site is static and there is no ability to customize the content for each web visitor. However, because this content is pre-baked these requests can be served very rapidly and very few server-side resources are needed. Whereas a “fried deployment” is made to order when requested from the web server. This requires server-side resources, but the web content can be personalized at the time of delivery.
Although these options represent 2 extremes, in reality these lines are often blurred. “Baked systems” often have provisions for dynamic content and “fried system” often have provisions for caching (pre-baking) parts of the web page.
Coupled vs. Decoupled Deployments
Central to the CMS is the editing environment that enables content authors to create web content. In a “coupled system” this editing environment is inseparable from the content delivery. Consequently, during deployment, the editing environment is also moved to the production server. It might be possible to disable access to this environment, but the editing environment still must be deployed as part of the web site.
Whereas in a “decoupled system” the editing environment and the delivery environment can be separated. This enables web content to be administered privately (on a private development server) and during deployment only the web content is deployed to the production server. In this environment content authors cannot make direct changes to content on the live web site.
Single server vs. Multi-server Deployments
High-volume web sites can easily exceed the capacity of a single server to serve all the incoming requests. In these scenarios, more web servers are added to handle the incoming traffic. These multiple servers frequently sit behind a load balancer which handles distributing the traffic evenly between the different servers.
Multi-server deployments must address the challenges of synchronization between these different servers. If each web server is pulling content from a central database,then this might not be overly challenging. However, if content is stored locally or if web project changes are being deployed, then it’s possible for web visitors to encounter inconsistent, outdated or broken results as they are randomly directly to outdated servers.
Single stage vs. Multi-stage Deployments
A basic deployment simply involves moving a web site from a development environment to a production environment. This represents a single stage deployment scenario. However, larger web projects might involve a staging server that is used for Quality assurance. In this environment, the web site must be deployed multiple times before it is available on the live web site. This represents a multi-stage deployment scenario.
One-way vs. Two-way Deployments
A one-way deployment assumes that information will only be flowing in a single direction. For example, the development environment represents the authoritative source of the project. During deployment, the development web site is moved to the production environment and the existing “live” web site (if it exists) is overwritten. If there are differences between these two environments then the development server is assumed to be correct.
Whereas, a two-way deployment must negotiate the differences between these different environments. For example, if the web site has comments or forums, then it’s easy to imagine that the live environment contains content that does not exist in the development environment. It would be inappropriate for this content to disappear during deployment. Consequently, these differences must be resolved and merged during the deployment.
Which deployment model is best?
For many small to medium web sites, deployment is something that happens rarely. It’s done during the initial launch of the web site and perhaps occasionally during upgrades. In those scenarios, developers must manually relocate files and export databases to recreate the web site in another environment. This process is often time consuming but if deployment happens rarely then manual deployment is not an overwhelming challenge.
Consequently, most small to medium-sized web sites will be well served by the following deployment models:
- Fried - content isn’t static and can be personalized during delivery.
- Coupled - content is managed on the production environment.
- Single server - if more servers are needed then they can be added without dramatic changes.
- One-way - after the original deployment the live web site becomes the authoritative content source.
This is also the deployment scenario most CMS’s readily support. However, this deployment model would present several challenges in a large-scale web site environment. Consequently, large-scale web sites can investigate other deployment models to minimize these risks.
What scenarios make deployment challenging?
The simple deployment model described above works for many web sites. However, this deployment model can become unmanageable when used with one or more of the following scenarios:
- Multiple hosting environments are involved (development, staging, production, etc.)
- Environments become out-of-sync (content exists on the the production server, but not on the development server)
- Multiple load-balanced servers are involved.
- Deployment needs to happen frequently
Some CMS’s included features to help organizations confront these challenges.
How can a CMS help with deployment?
Most CMS’s have no features to help with deployment. Instead, this is task that must be managed manually by a developer or system administrator. However, CMS’s that cater to larger web sites might have features that help address the challenges identified above.
Tools for web project deployment.
These tools are useful for load balanced environments where the web project (and the files related to the project) need to be deployed to multiple servers. In this example, a CMS’s deployment tools could be used to easily migrate the development web site to 10 different load-balanced servers. Alternately, these tools could be used to deploy a web site through multiple staging environments.
Tools for content synchronization.
These tools are useful when content becomes out-of-sync between different environments (for example, development & production). In these cases, a CMS’s content synchronization tools can help resolve the differences between these different environments to re-establish synchronization.
Flexible deployment models
These features are useful in high-volume web sites where it might become necessary to rely on a baked model for content that is too expensive (from a performance perspective) to render dynamically on-the-fly.
