Environments and Implementation / Life Cycle Strategy
Nov 12, 2012
By: Will Ezell
Once you know dotCMS is, in terms of functionality, the right product to host your website, one of the questions that is next to be answered is: how many servers will you need?
In this blog you will find the description of the basic set of environments that we recommend you to plan for during your initiation phase.
Also in the blog, we will talk about the different strategies you may follow to launch your new sites hosted in dotCMS and the life cycle that you will need to considered once your new website is live.
We recommend you to plan to have three environments: development, QA, and production.
There are three different types of development environment that you will need to combine according to the role and expertise of the members in your implementation team.
All Local: in this type of environment both dotCMS and its database are local. This type of environment is highly recommended for plugin developers that will need to restart and rebuild the application often.
Local dotCMS, remote DB: in this type of environment dotCMS runs locally but the database schema is hosted in an external/shared database server. This type of environment is also recommended for plugin and backend developers needing their own instances but without enough resources to run the database in their personal computers. It is important to note that even when the database server can be shared among multiple users, each dotCMS instance needs its own schema.
Sandbox: you will need one sandbox to allow all your plugin, backend, and frontend developers to integrate all their work before starting your QA tests. Both database and dotCMS can run in the same server, but you can also host your database schema in an external/shared server.
The figure below illustrates an example of development environment where one plugin developer, two backend developers, and one frontend developer share the sandbox environment.
Quality Assurance and Production Environments
We deal with these two environments together, for your QA environment should mimic your production environment.
Clustering is the first characteristic that you need to assure for your production environment. Not only does clustering allow you to handle high picks of traffic, it also provides you with a second dotCMS instance in case one of the servers in the cluster fails. Clustered environments are accompanied also by the necessity of a load balancer and a storage unit for shared folders (basically dotCMS' assets).
For production environments, it is very important to assure that your database manager runs in a different box. We also recommend having a backup mechanism that allows to restore the database quickly in case of failure.
The figure below shows the example of a clustered environment. The minimal configuration we recommend consists on two clustered servers. Adding servers to your production environment is just a matter of configuration for dotCMS; it is not complicated at all. However, you will need to consider the new load that that or those servers will generate for your database server and other specific network configuration required in your organization.
Other than the resources assigned to each server (memory, disk, etc), the main difference between your QA and production environments is that you only need two servers in your QA environment to be able to test the cluster features. For example, if you determine that you need 5 servers in your production environment, you do not have to add three more servers to your QA environment; two will be enough. If such difference exists between your QA and production environments, you will need to determine a conversion factor to be able to compare results between them while executing performance tests, though.
The figure below shows an example of a QA clustered environment.
The database and shared folders could also coexist in the same server in a QA environment as long as you make sure that server has plenty of space to host all the data from the production servers.
Implementation and Lifecycle Strategy
The go live strategy for a brand new dotCMS installation basically depends on when you will have your environments available to start implementing.
When the development environment is the first being built ...
- Implementation starts on your development environment.
- Once your QA environment has been set up, database and assets are copied from sandbox to QA servers.
- Plugins need to be deployed and configured in QA following the same installation plan that will be applied later on to production.
- The testing is executed in the QA environment.
- Developers fix in sandbox the issues reported by the QA team.
- The fixes are applied into QA following a schedule that both development and QA teams have agreed on (once every day, once a week, per module, etc)
- Once all the iterations of tests and bug fixing have ended, database and assets are copied from QA to production. Plugins are deployed into production.
- A final set of tests is executed in production.
- Voila! Your website is ready to go live.
When the production environment is the first being built ...
- Implementation starts on the production servers.
- Once implementation is done, QA tests are executed in production.
- Developers fix in production all the issues reported by the QA team.
- Once all the iterations of tests and bug fixing have ended, your website is ready to go live!
- Once sandbox and QA environments have been set up, assets and database are copied from production and plugins are deployed.
When in the case that all the environments will be available at the same time, you will need to consider that the first option presented in this blog (implementation starts in the development environment) is a more organized way to execute the implementation that allows your development and QA teams to work in parallel. However, the second choice (implementation starts in the production environment) is a more expedite option that avoids the time spent on copying and configuring three different environments before being able to go live with your new dotCMS website(s).
Once your dotCMS instance has gone live, the life cycle for your new website(s) must take into account: development of new functionality, bug fixing, and new dotCMS releases.
1. Development of New Functionality
Your implementation life cycle must assure all new functionality goes through the next steps:
- Requirement definition
- QA tests / bug fixing
- Documentation (user documentation, installation plans, etc)
- Move to production
The length of each one of those steps and whether you group multiple changes in the same release or deal with them individually are two of the aspects you will need to define.
2. Bug Fixing
The implementation of a fix follows the same steps listed for new functionality. Based on the impact and priority of the functionality being affected by the bug, you will need to make a decision on whether the fix makes it to production immediately or is added to the life cycle of new functionality.
3. New dotCMS Releases
dotCMS releases are available periodically, and it is very important that every new release that you plan on installing on your production servers gets tested in your QA environment to detect and handle any changes introduced that may affect your custom code.
It is also important to keep the changes introduced by your development cycle separated from any new dotCMS release. If your changes and a new dotCMS release are tested at the same time in your QA environment, it will be more difficult to identify the cause of any error you may start experiencing in functionality that used to work before.
In conclusion, you should consider three environments (development, QA, and production) when implementing your new website in dotCMS. Depending on how those environments will be available, you will also need to decide where (development or production) your implementation will start.
We hope the information in this blog will help you define your implementation strategy after choosing dotCMS as content management system.
Please also take a look at some items in our documentation that will give you a better understanding about the set up process: