Development Environment – Concepts

Time is important and at ClusterCS we value this resource immensely. Development environments (Dev Env) is one of the most powerful features of ClusterCS and it really helps save a lot of time.

The workflow for making updates to a website by creating a development environment where changes are made and tested and then migrated back to live can be a very time-consuming process. ClusterCS helps reduce time spent in this repetitive migration actions by a very high degree. Automating this process also means we avoid human error which ensures a higher quality of the work and saves time spent in debugging such errors.

A website requires continuous maintenance and/or development of new features. The bad way is to do such work directly on the live environment – installing a plugin, working on a theme or some code. This can expose errors to the visitors that are being active on the website. The right way is to create a separate development environment where changes can be made, verified and then copied back on the live website. But this normally comes with some costs, generally in time spent in creating the development environment and then migrating back and forth but for a lot of people that are not technical enough it can also get to be a pretty impossible good practice.

ClusterCS automates this process by providing an easy interface to manage the process of creating environments and migrating from Production to dev and then back. A process that can often take a few hours, can be now done within a few minutes by developers and non-technical people alike.

The idea is simple. A ClusterCS domain contains the primary “Production” environment which is the live website visitors see and then multiple development environments can be created behind the so that work can be done behind the scenes and pushed to Production only when ready and verified. Let consider a couple of workflow examples.

Let’s suppose I am a blogger, writing articles and I am pretty good at managing my WordPress edit, publish and eventually plugin management workflow. I would like to update my WordPress core or plugins from time to time and sometimes I find nice plugins that enhance the blog functionality. My problem is that I don’t know if these updates will break my website and cause downtime that affects my visitors. With ClusterCS workflow I can create a new development environment, migrate from Production to dev, make changes, test everything under the dev environment and then migrate back to Production when I am satisfied. All these actions are simplified to mostly single clicks and where more options are available to accommodate advanced scenarios, everything is preconfigured that works well for such simple cases. Between migrating from Production to dev and then back, I need to make my updates and test. Each development environment has a special link in the interface that opens that environment specifically for me, under the same domain URL, while the rest of the world sees the normal Production website. This is very important in cases such as WordPress where a URL change would imply changes in the database to replace the live domain URL with the development URL. This is not the case with ClusterCS because you can “see” and update the development website under the same URL without affecting website users. I can now login in this development instance of my WordPress blog, update or install plugins, test the front end and when I am satisfied I can use the Migrate section to publish my updated website to the Production environment for all users.

If I am a developer and I want to have a more solid approach by using GIT between my development branches, ClusterCS can automatically enable GIT support and manage each environment as a GIT branch. Each domain will have its own GIT repository which contains a branch for each development environment created. Migrating from one environment to the other can be done with the “git push” mechanism to ensure correct workflow and git tracking. I can simply make updates through FTP/SFTP to the specific environment code and when migrating to Production or another environment, ClusterCS will execute a “git commit” on the source branch and use “git push” with post-update hooks as the migration mechanism. Multiple developers can work in this manner in parallel on a dedicated environment and multiple environments can be used for various features that can be developed in parallel. The GIT repository can also be accessed directly through SSH for direct management of operations.

Development environments support advanced scenarios. ClusterCS can manage simple standalone servers and large web clusters. The migration and tracking options allow managing more complicated cases just as easy. A section called “Tracked Items” allows you to manage and define special files that can be automatically overwritten after a migration with environment specific variables.

A license addon is required in order to use “Development Environments”. A trial period is also available to experience this feature. The paid license is a single addon paid monthly and is not a per server or per domain cost. Since ClusterCS can allow you to manage all your servers under the same interface, enabling this license add-on gives you access to this feature for all the servers and domains under your ClusterCS instance.

Do try it and see how easy and time saving this is. Any feedback is very welcome and doesn’t hesitate to contact the support department for the assistance you require.