The Dev-Test-Deploy Merry-Go-Round: How AdroitLogic IPS Fits In!

Now that we have heard of what IPS is and what it has in store for you, it's probably time to delve into the details of how it can actually help improve the enterprise integration lifecycle of your organization.

A typical enterprise integration project involves multiple dev-test-deploy cycles. The dev cycles are also usually further decomposable to a certain degree of testing, possibly on the developer's system as well as an actual sandbox inside the deployment environment. QA-level testing is also usually carried out in a sandbox closely resembling the final production environment. Finally, once you are ready to go production, the current version of the project is 'frozen'; any new incoming changes, fixes or features, and you spin off the next cycle (version) of the project, basically on the same, or a slightly modified, set of environments.

In reality, from the project's point of view, what actually changes when you migrate a project across different environments, is its set of externalized project properties and configuration artifacts (external config files, custom libraries and such); the source code and resources bundled inside the project remain unchanged. What does this mean? That you can simply maintain a different set of properties and configurations for each environment, switching them around when you want to follow the dev-test-deploy cycle!

IPS does just this, along with a lot of additional cool features. It abstracts the notion of environments with an entity of the same terminology: environment. Following our dev-test-deploy convention, IPS offers DEVELOPMENT, TEST and PRODUCTION environments for its clusters. Migrating a cluster from one environment to the next is as easy as selecting the new environment from a drop-down list and clicking Deploy.

Each project can have a distinct set of property values for each environment. Projects deployed in a cluster inherit their environment from the cluster runtime, and environment-specific properties and configurations are automatically injected to them at startup. While properties are not directly inherited across project versions, you can copy existing properties across versions of the same project.

For example, suppose you have a cluster http-cluster1 and need to spin off a peoject http-project currently at version v1 (hence the project version named http-project-v1). You would

1. create and develop the project (/x:project[id] and /x:project[version] in project.xpml set to http-project and v1 respectively) using UltraStudio,
2. build and upload the project to IPS,
3. via the edit project version perspective of IPS dashboard, define appropriate values for externalized properties of http-project-v1 for each environment, and
4. add the project under cluster http-cluster1, along with any custom configuration artifacts, creating a new cluster version, say http-cluster1-v1.

Now, when you are

1. in a dev cycle, just set http-cluster1 to DEVELOPMENT and redeploy http-cluster1-v1.
2. in a test/QA cycle, set http-cluster1 to TEST and redeploy http-cluster1-v1.
3. in the next dev cycle following the QA,
   • upload an updated revision of http-project-v1 to IPS,
   • set http-cluster1 back to DEVELOPMENT,
   • create a new cluster version http-cluster1-v2 with the updated http-project-v1, and
   • deploy http-cluster1-v2.
4. traversing the dev-test loop, keep on with the environment switch and project update procedure.
5. ready for production, set http-cluster1 to PRODUCTION and redeploy http-cluster1-vx, the cluster version containing the latest revision of http-project-v1.

Furthermore, when you wish to roll out a new version v2 of http-project, you would simply

1. build and upload http-project-v2 via the IPS project uploader,
2. during the configure project properties stage of the upload process, copy properties from http-project-v1 for all environments using the import from project version option,
3. create a new cluster (say http-cluster2) and deploy http-project-v2 on it,
4. continue with the dev-test-deploy cycle for http-project-v2 as before, using cluster http-cluster2, and
5. once http-project-v2 is solid, dump http-cluster1 and migrate http-cluster2 to PRODUCTION.

As you can see, IPS undertakes many of the tricky aspects of the dev-test-deploy cycle such as artifact management, environment and property governance, and versioning, and promises to deliver a smooth enterprise integration workflow for your IT department.