Three HIFIS environments

It’s considered a best practice in the IT world to have more than one copy of important software that you’re developing.

For example, ACRE Consulting has a website (you’re on it right now!). If I wanted to make a change to it, the best practice would me for me to have a testing site where I could muck around and change things without worrying about what would happen to folks like you who are currently taking an online course using my website!

In fact, for software like HIFIS, most IT folks would recommend a three environment configuration. An environment is like a copy of the software that is used for a specific purpose.

From Atlassian

Production Environment

The first environment is usually referred to by techie folks as the production environment but for non-techies, you might think of it as the live site.

It’s where your real live staff are entering real information about real clients in real time (hopefully). At this point, you don’t have it set up yet, but it will be the version of HIFIS that your staff see. Because it’s used by all your staff, your IT Support will want to make sure there’s a lot of support surrounding it. They’ll want to make sure things like firewalls are in place so the data can’t get hacked, and they’ll want to make sure that there’s enough bandwidth so that it won’t slow down or crash if too many people are trying to use it at the same time.

Development Environment

At the other end of the spectrum is the development environment. You might also hear this called the testing environment or even the sandbox.

The idea here is that you can use this environment to try out new things. For example, when there’s a new update to HIFIS, you might want to install it here first and see what’s in it. Or, if you’re trying to add in a new program area, you could use this environment to experiment with modules you aren’t normally using. It’s a safe place for you to make whatever huge changes you need to try out, with no fear of getting in someone else’s way, or impacting day-to-day HIFIS use. Note that demo.hifis.ca is a development environment, so you don't need your own, strictly speaking.

Staging Environment

In between, you have a third environment that is often called the staging environment but might be called something entirely different, like a pre-production environment or a training site.

The idea of a staging environment is that it is a copy of the production environment that is not used on a day-to-day basis with real clients and real data. It’s a simulated environment that should feel as much like the production environment as possible. The most frequent use for a staging environment is to deliver training. If you can train staff and give them the freedom to add in fake clients and dummy data while they’re still learning, but still have all of the configuration look the same (same rights, same shelters, same programs), they’ll be able to easily apply what they learned in training to doing their actual job in the production site.

Another important use for the staging environment is it’s a bit of a testing ground for the production environment. Let’s imagine you want to make a change in the software. You test it out in the development environment and it seems like a good idea. Next, you can test it out in the staging environment and what kind of an impact it would have on your real staff, real clients, and real data… without actually impacting them.

Putting it all Together

Your IT Support may disagree with this approach, and that’s okay. They’re the IT experts in your community, and you should listen to them! However, the most common configuration goes like this:

You have three environments, as listed above. When there’s a new version of the software, or you want to make a change, first we test out the change (like installing the update) in the development environment. If everything goes well, we apply the same change in the staging environment, and test it again. If it still looks good, we apply the same change in the production environment and do a quick test. Theoretically, it should be fine because we already tested it in the staging environment.

Then, after the change is applied, we take a backup or copy or clone of the production database and copy it over to the staging environment, because – and this is important – we always want the staging environment to look like the production environment. That way, it’s going to be ready for the next test. We’ll also probably want to copy the production environment to the development environment, although we don’t need to do that as often.

When we want to make a change, like modify some user rights, add a new service provider or setup a new program, we make that change in the staging environment, and test to see what the impacts are. If the impacts are what we're looking for, then we make the same change to our production environment. If our change doesn't turn out the way we want, we haven't caused any damage, and we can either revert the changes (by restoring a backup version of our staging database, or simply re-copying the production database to staging) or ignore them and try something new.

Finally, when training is being delivered, you set up some training logins in the staging site, and deliver training in the staging environment. When the staff have completed the training, new user accounts are created for them in the production environment.

From Wordpress At Scale