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.
We deal with these two environments together, for your QA environment should mimic your production environment.
The amount and size of the servers in your production environment will depend on traffic, technology used to implement your frontend functionality (pure html, javascript, ajax, etc), and the integration required with external servers among other factors. We will present next the minimal configuration we recommend for a production environment; however, further analysis to adapt this architecture to your unique conditions is required.
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.
The go live strategy for a brand new dotCMS installation basically depends on when you will have your environments available to start implementing.
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:
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:
Maintaining or achieving a global presence requires effective use of resources, time and money. Single-tenant CMS solutions were once the go-to choices for enterprises to reach out to different market...
What’s the difference between a headless CMS and a hybrid CMS, and which one is best suited for an enterprise?
What is cloud computing, and what benefits does the cloud bring to brands who are entering into the IoT era?