Everything you need to know about OTAP

Everything you need to know about OTAP

Within the developer world, OTAP is a household word. working with OTAP is something that is almost automatic for many developers. But what exactly is it, how do you set it up and, considering it is not a very new method, is it still up to date?

What is OTAP

The acronym OTAP (In English, DTAP) stands for Development, Test, Acceptance and Production. It helps software engineers know what stage the development of a particular piece of software is in. The OTAP lane goes through four phases. OTAP can also be used to efficiently and conveniently implement releases and patches. The four phases of the development street are as follows.

Phase 1: Developing

The application, or a component of it, is first developed in a dedicated development environment. Here, there are usually one or more people in a development team working on one joint version. Important here is the registration of the different versions.

Phase 2: Testing

Often the piece of code created is transferred to a test environment. Both technical and functional testing can be done on this environment. This can be done at night, in which case the results are ready for the development team the next day. But it can also be done during the day and then developers sometimes have to continue with other functionalities until the tests are completed. When a release is continued, this release can be fully tested by all parties involved.

Phase 3: Acceptance

After approval, the application can be installed in the acceptance environment. This is carefully documented in a script. The acceptance environment is, in terms of hardware and software, similar to the production environment. This makes it possible to see if everything works without affecting daily use.

Phase 4: Production

After the application is accepted, the application is implemented within the production environment.

How to implement OTAP

Your OTAP environment often runs on an external server, such as Microsoft's Azure Devops. But you can also choose to host it yourself, which can be done with Teamcity from Jetbrains, for example. There are lots of packages to choose from. But ultimately it comes down to configuring a number of "builds" that can deploy part or all of your codebase to an environment. Each build has multiple build steps. A very simple build, to an acceptance environment, for example, might consist of 3 steps:

• Retrieve the code from your version-control system
• In this step, you may want to apply some environment-specific fixes within your code, or run a script to zip your code
• Deploy the code to the acceptance environment

The tools already mentioned have a very handy interface for this. You can often set up an entire OTAP street just by clicking around. Often you will find that larger and complex projects require additional steps, for which you will have to write your own script. But even these are often small scripts that work in steps.

Is OTAP still of our time?

In an OTAP environment, before you get to production, you have to repeat a number of steps with each environment. To that end, there are a number of best practices that ensure OTAP can work well.

For example, it is helpful to ensure that the entire development street is already in place, a lot of testing can be done with actual data, and it is smart to involve the customer in the entire process.

Nowadays, "testers" and "developers" are no longer defined tasks. The whole project is done as a team and everyone is responsible for testing and developing the software. Of course, partly because of such a new division of roles, processes like OTAP can always be more efficient.

If we take a look into the future, OTAP will be replaced by a container system. The idea here is that your system is made up of several smaller subsystems. The idea is then that you deploy the entire system, including the subsystems through the entire OTAP. So you then deployed the entire system four times. You can also test each individual subsystem separately and then you do not have to go through the four steps of OTAP with your entire system. This saves time and is therefore cheaper.

Especially for larger companies, it is difficult to simply move away from an OTAP environment, so OTAP is expected to stay around for a while.

In conclusion

So OTAP stands for develop, test, accept and produce. Your OTAP environment often runs on a remote server, and building the various environments often consists of three steps. OTAP is a method often used today, especially in larger companies. We just expect that a container system will replace OTAP.

Is OTAP nothing strange to you, are you a developer looking for a new career? Then take a look at our jobs page! Or read the blog about the work of a DevOps Engineer.

Colin Hammer

Colin Hamer is a Software Engineer at CaseNine. He is responsible for various Salesforce projects at clients.