The ESB Environments
In the Deloitte Middleware team, we have multiple environments for each stage of integration development. An environment is a place where we deploy, test and develop our products, at their various states of readiness.
We have 4 different environments according to the middleware development lifecycle:
ESB Development - ESB-DEV-01
The first step in the life of an integration, change (or a new endpoint !filler!) is the Development environment. Typically this is only used for internal ESB development purposes.
Our developers work until the product is ready for the first functionality testing and it is deemed usable. Then the related Pull Request (PR) is created and reviewed by our development Leaders. After it is approved, the changes are automatically deployed into the next environment in line, the TEST environment.
ESB Testing - ESB-TEST-01
The testing environment's name might be tricky. This is not where the final product gets through the final Quality Assurance.
Here, developers are able to make further refinements to the product, adapting it to the ever changing requirements. Also a basic level of testing is done to get rid of major and minor bugs alike.
Based on the consumer application requirements, we can recommend it only to be connected for other Development systems
ESB Staging - ESB-STAGE-01
As soon as the development is tested and ready assessed ready for production release, it still has to go through Quality Assurance. This usually happens ~1 weeks before the deployment to production. As soon as the release candidate is deployed, our dedicated ESB QA team meticulously tests the product in every aspect imaginable. They do not leave room for error.
The release candidate deployment is communicated in advance. Proper testing of the consumer application with the new release, is the application owner's responsibility.
This environment is recommended to be connected to the consumer's Test and UAT environments
ESB Production - ESB-PROD-01
This is the production environment. The products deployed here are working with live data and loads. If a change request, or a modification is required, the changes must go through the entire process again, to assure maximum quality, and minimalize errors and downtime.
Release to the production environment happens on a monthly basis, however dedicated bugfixes and releases can happen more often. Any of these activities and planned downtimes of any integration are communicated in advance, as part of the Release communications.
This environment is recommended to be connected for the consumer's Pre-Production and Production environments.
Want to know more?
Check out how we authenticate API calls, or check out our APIs key features!