In this post we will cover "Preprod" tooling from the Gartner Toolchai, which Gartner as follows:
Preprod typically runs simultaneously with create and verify, and includes the activities required once the release is ready for deployment. Preprod may include packaging, the activities associated with automatic release, and holding or staging the business application or software ready for release. This activity will be determined by how the application is released into production. It should not be considered a barrier but a necessary control function to aid business readiness. It is often kept synchronized or aligned with the other DevOps environments by an environment management team. This is sometimes part of the DevOps team and sometimes separate and more aligned with infrastructure (see "How to Change the Role of Ops in DevOps").
Source: Choosing the Right Tools for Your DevOps Toolchain, Published: 10 April 2017 ID: G00322126, Analyst(s): David Paul Williams, Thomas E. Murphy
In another publication Gartner says the following:
Preprod includes the activities required once the release is ready for deployment. Preprod may include the activity to automatically push the application to release or a location used to hold/stage the software ready for release. This activity will be determined by how the application is released into production. It should not be considered a barrier, but a necessary control function to aid business readiness.
Source: Avoid Failure by Developing a Toolchain That Enables DevOps, Published: 16 March 2016, ID: G00293223, Analyst(s): David Paul Williams | Thomas E. Murphy
Following is a summary of Preprod activities:
- Autorelease (e.g., application release is automatically pushed)
- Triggered release (e.g., upon a "ready state" being met)
- Release staging/holding
- Release approval/preapproval
- Release package configuration (if required)
Some of these Preprod tools as listed by Gartner:
- Clarive Software
- Electric Cloud
I would say that preprod is almost a copy of what you will have or need in production. All debugging features will be set off or removed. It is a final test to make almost sure that when you move to production everything will work.
A preprod step is almost a must when you have many dependencies: a program doesn’t just run on his own but interacts with other applications, works with a database, files or application servers. One little difference between your testing environment and production can make a huge difference and cause your new release to fail.
Every situation is different. It is up to you to see what internal process you have today (WHAT is) and if you want or need to change it (TO BE) and how you will do the transition.
As part of that process study you should identify what the differences are between your “verify” environment and your production environment. In the preprod environment you should make sure to tackle all the differences between the “verify” and production environment. Take care of all debug code, make sure needed database, application server and any other dependency are handled correctly.
For more information