Enterprises rely on their software development teams for building and maintaining a variety of applications. In a world driven by content experiences, ensuring that these applications are working properly is fundamental for the customer experience and the success of the organization.

For software developers, integration, testing and quality assurance are critical parts of the software development lifecycle (SDLC). Whenever an application needs a new feature, a patch, upgrade, testing is done to ensure that the code is functioning correctly. To adequately facilitate these tests, software teams frequently rely on lower environments.

This article will explain more about software development environments and the importance of lower environments in your CMS infrastructure.

Explaining Software Environments

A software environment is a replica of the production environment that developer and DevOps teams use to develop, test, and release complex software systems. There are different types of environments, and they essentially form a tiered structure for different stages of application development.

Changes are made and deployed to each of these environments before the application goes live, and the number of environments will vary based on the requirements of the enterprise. However, for most teams, the usual lower environments are development, testing/QA, staging, and production.

Development: This is a workspace where developers deploy initial code and conduct integration tests. This is a basic integration environment where developers are starting to mix their code with others working on the same project and making sure that it works in conjunction with each other.

In this environment, it’s common to be connected to other resources, such as a development version of the LDAP server or a development version of the inventory or database development version of the CRM. The purpose of this environment is to perform development integration testing.

Test/QA: A test environment where teams conduct quality assurance on a release candidate, and is usually a one-for-one replica of the Production environment. This environment has a copy of the same content and data in production, and is used by the quality assurance team to prove out all the software, make sure that the features and bug fixes all work exactly as they are specified. Any bugs or defects that might impact the application are dealt with here, and sent back to development teams for resolution. In addition to functional tests, performance, reliability, security, and user acceptance testing may be performed in this environment as well.

Staging: A pre-production environment where additional tests are performed before deploying the application to Production. Here the application will function almost as it does once the end-user sees it in Production. Usually, this environment is used by those outside the QA team, such as legal, C-level execs, PR, and other business teams who want to perform their own reviews/tests.

Production: This is the live production software that is made available for end-users.

Some organizations have even more environments. For example, there may be an environment set aside for load testing, or an environment which holds an exact copy of production from yesterday so that any issues that came up in production can be replicated. And some teams have multiple copies of these environments because different groups use them.

Advantages of Having Multiple Environments

Here are some advantages of having multiple environments for software development.

Productivity: Multiple environments allow software teams to work in parallel. Developers and software testers don’t need to wait on each other to do their work.

No Downtime: Testing and staging environments help software developers work on systems that are completely decoupled from the production system, and eliminate the potential for any downtime.

Security: Team leaders can limit access to specific environments to prevent accidents when onboarding new developers, or when multiple projects are being worked on simultaneously.

Experimentation: With multiple environments, developers can freely experiment and introduce new features and test new concepts into an environment without interfering with production code.

Which Environments Does Your Team Need?

The number of environments your business needs will depend on several factors. Some of the questions that might be asked include: How often are you doing releases? How many concurrent groups of developers are working on features simultaneously?

You need to know what you want for your throughput, what your cadence will be, and then your team can design your environments to fit within those parameters.

CrafterCMS: Supporting Multi-Environment Configuration

For content-driven digital experience applications, having one or more lower environments can be beneficial to both operations, benefiting both the development team and content team.

CrafterCMS easily supports any number of lower environments. Its distributed Git-based content repository makes it easy to move content and code among environments. For example, developers can pull production content down to the development machines and/or any lower environment with a simple Git “pull” operation. Likewise, moving code forward from lower environments to upper environments (or releasing to Production) is as simple as a Git “push” operation.

CrafterCMS also provides APIs to integrate the content management platform and application into CI/CD DevOps pipelines, so the benefits of continuous integration and delivery across environments can be realized.

While setting up and operating multi-environments with CrafterCMS is straightforward (and much easier than most database-oriented CMS platforms), it also has a cool feature for creating a Staging delivery target in the Production environment. In many cases, this eliminates the need for an extra Staging environment altogether. Within the Production content authoring system, you can configure a “staging” publishing target in addition to the “live” end user target. This is useful for enterprises that want non-CMS users (HR, C-level execs, PR, Legal, etc.) to preview and either approve or reject certain content or functional changes just before going live.

CrafterCMS also provides unique support for DevContentOps processes, which enables developers, content authors, and operations to collaborate seamlessly. DevContentOps processes support continuous integration, continuous delivery, and continuous publishing and streamlines the development, testing, release, and publish cycles of content-driven applications. For teams creating content applications, it’s critical to include the content management system and content teams in the modern DevOps process, and this is best accomplished with DevContentOps that is enabled by CrafterCMS’s Git-based content repository.

Learn more about CrafterCMS multi-environment support and DevContentOps by reading the White Paper: What Is DevContentOps?