Separating Development and Production

3 years ago 2 mins read

As an organization becomes more dependent on Rock for the day to day operations, it’s common to create a development (or some might say "staging") environment to be able to test new ideas and recent releases.

Loading the Elevenlabs Text to Speech AudioNative Player...

Recently, we were working with a church on a new website and came across a situation that was less than optimal. Their infrastructure had originally been configured so that their development web server was located on the same VM as their production Rock instance. We wanted to take some time to discuss why this is not a good idea in case anyone else finds themselves considering the same pattern.

The reasons why you would want to separate your development and production environments fall into two categories: shared resources and complex configuration. Let's look at each in detail.

Shared Resources
The primary concern about running both production and development on a single server centers around server resources. Development environments are created because you want to do things in them that you would not want to do in production. Production environments on the other hand are critical to the day to day operations of your organization. These two missions are fundamentally at odds.

During a website project we include a step to consider if the current environment has enough capacity to support the load of the new site. Because their current partner does not maintain an architecture map for the church, there was no indication that this anti-practice was in place. We did hear that there were some current concerns about weekend check-in performance.

Consider that last point: there are scaling questions centered around check-in performance. The evaluation of the current state and possible fixes is made much more difficult knowing that one VM is serving two roles. If you go back to the Azure performance logs and look at CPU and memory usage during the check-in periods, there is no way to know if the load came from the production IIS instance or the development instance. Perhaps someone was using or testing something on the development machine at the same time.

Complex Configuration
If shared resources were not enough to consider this a bad idea, we also need to look at the configuration required to run two instances of Rock on the same VM. This primarily comes down to the IIS bindings required to separate traffic coming in on one IP address but being serviced by two or more IIS instances. In this configuration, each host name needs to have two bindings (one for HTTP and one for HTTPS).

With a normal IIS installation all traffic is sent to a single IIS instance. This makes adding new host names (say for a new microsite you have just added) easy. Just adjust your DNS and you can now be assured that Rock will get that traffic. When you run multiple instances, you will now need to also add two new binding rules to the production instance of IIS.

While these settings are not rocket science, they are also not expected and represent another point of failure.

Splitting production and development environments is critical to a stable and predictable Rock environment. This is especially true when you consider that an Azure burstable VM capable of running a development environment can be had for around $30 per month.

At Triumph we are always passionate about doing things with best practice in mind. We are also equally passionate about sharing these best practices with the Rock Community to help educate and help as a way of giving back.

Let’s get to work

Ready to bring your Rock RMS ideas to life?

We’re here to help.

Contact Us