Ditching the traditional DTAP with Crownpeak DXM
Ensuring that software releases, patches, and new features work consistently and immediately, requires a series of non-production quality assurance gates - each passed, before promotion to the next. Once all checks have been made, and quality assured, a release to the production environment will be made, completing the process. Crownpeak DXM greatly reduces the overhead associated with the traditional DTAP environment.
The traditional Development, Testing, Acceptance and Production (DTAP) challenge
The licensing commercials for most enterprise-grade CMS platforms are likely to be relatively similar. However, the cost of the pre-production environments required to ensure a consistent, high-quality software development lifecycle (SCLC) is the one key factor that is often hidden in said advertising.
A traditional DTAP approach
Ensuring that software releases, patches, and new features work consistently and immediately, requires a series of non-production quality assurance gates - each passed, before promotion to the next. Once all checks have been made, and quality assured, a release to the production environment will be made, completing the process.
The production environment must be built in a fault-tolerant configuration (to prevent outages). In many cases, companies assert that pre-production environments can be “smaller” or “lighter-weight.” However, you must fix issues created by inconsistencies with network configuration, scalability triggers, and application behaviour. If you don’t see them before a production release, how can you assure quality? In contrast, ensuring that the pre-production setup mirrors production leaves little excuse for releasing issues to production: the result, a happier customer.
Ok, so we’re sold? Good.
Now think about the pre-production environments that you need. You’ll want one for each developer to work on (ten developers?), a combined one for system integration testing, and another for quality assurance testing. You need to: stand-up the virtual machines that these will run on; tie them together via continuous integration; install server components; configure high-availability; configure source control, content synchronisation, etc. And this isn’t a one-off either! Within the CMS lifecycle, you might upgrade the software version multiple times. That means that you’ve got to update the entire non-production stack too (well, likely you’ll need various, side-by-side environments to make this happen). All of this will require not only a significant cost overhead in infrastructure but also many, many, person-hours.
Once these traditional DTAP costs get added to the initial license outlay, suddenly the licensing costs don’t seem like such a deal.
How does Crownpeak DXM differ?
Crownpeak Digital Experience Management (DXM)’s Decoupled Content Deployment Architecture provides organisations with complete flexibility in what, how and where content is distributed. In today’s modern, customer-experience-focussed world, the ability to curate content in a single location, taking advantage of centralised governance while enabling local market flexibility, then deploying this optimised content to the right channel for the customer at the right time, gives global organisations a strategic advantage over their competitors.
The advantage of being able to publish content anywhere not only relates to datacenter locations around the world, but also allows the separation between pre-production and production environments alike.
DXM has the notion of a “Project.” A Project contains all of the configurations to create one or more digital experiences - it’s where a developer will live during the build. Configuration inside a Project is the same as any other type of content. It has full version history and rollback capability, which means mistakes are easily fixed.
A Project can also be “Branched,” as many times as you like, which allows multiple branches of a Project active at any one time, mirroring the traditional DTAP approach (e.g., development, system integration testing, quality assurance, staging, and live).
As DXM separates the management of content (where your marketers work) from the delivery tier (where your customers visit), as well as delivering the entire management tier as a multi-tenant SaaS-based service, you can use the same development platform to build your configurations, work within the appropriate “Branch,” and then publish your changes into one of many DTAP targets.
And the best thing about it? You didn’t have to stand anything up - Crownpeak did it all for you!
In the topology above, all development infrastructure is managed by Crownpeak. This is optional. DXM can as easily deploy to any external location to support your preferences.
What about the content?
One of the most challenging things during the SDLC is managing the need for both content freeze, and the marketers’ need to deploy content. Typically, this involves a considerable content synchronisation exercise, likely over a weekend, with the CMS in “read-only” mode.
But not with Crownpeak!
As DXM now manages the entire content and development lifecycles, you can control how, when, and where content gets deployed too. A standard feature of DXM is to “back-publish” content to each lower environment when it is published higher in the DTAP workflow - So, anyone using the lower targets, whether developer or marketer, will see the most recent content.
However, sometimes, you want to make a distinction between the varying roles within an organisation. Enter DXM “Workflow Filters”. Workflow Filters allow you to specify rules around who can publish content and where.
In general, you don’t want marketers to be accessing, nor actively publishing content to our pre-production environments. Their world is production (i.e., staging and live). In contrast, we don’t want content being created by developers and making it into production. So, configuring a set of Workflow Filters to restrict our differing roles from working outside of their world is the way to go.
As you can see in the diagram above, developers are now free to create their own “test content,” safe in the knowledge that it will never leave pre-production. At the same time, marketers can also ensure that all of the features the developers are working on will have been tested using the most recent content. The result? No surprises at the end of the SDLC.
In summary
Following a traditional DTAP approach doesn’t mean that you have to build and manage it all yourself. Undoubtedly, there is somewhat of a paradigm shift from managing your infrastructure to migrating to a SaaS-based SDLC.
While a traditional approach allows companies to “continue with what they know,” the down-side, especially in the CMS-space, is a model that is typically over-costly and glacial - often to the detriment of those they are trying to serve.
In contrast, adopting an SDLC that is SaaS-based, globally scalable and governed, ensures faster time to value, lower overall TCO, and, frankly, fewer headaches! This is the Crownpeak difference.