Development governance is a common problem for any organization developing applications to cater their business needs.
Any service or application that is being developed has a lifecycle. From development to being in production, we have various roles involved such as developers, testers (QA), IT folks (Dev Ops / Tech Ops). As the service or application propagates through the lifecycle, the related artifacts (code, configurations, etc.) as well as know-how needs to be propagated and handed over to related parties playing various roles.
One of the challenges in the management of this life cycle in development governance is to make sure that, we have identical setups across various environments used. For example, the QA setup, need to be similar to the staging. And if developers made assumptions that are way off to that of the production system, and they have no way to verify the real aspects, there will be loads of corrective fixes left off till late. In short, development testing, QA testing, staging and production should have identical, or at least near identical setups.
Another challenge is the propagation of artifacts. Where should the QA should pick what to be tested and where should the Dev Ops pick the artifacts to be deployed to staging and from staging to production.
To ensure that we maintain uniformity across environments, and we have means of enforcing the proper process and means of artifact migration and management we can turn to cloud computing.
The cloud environments cater for various roles, to deal with their activities in the respective lifecycle stages of the service or application. The cloud environments can be hosted with identical software. The Platform as a Service solutions such as WSO2 Stratos, can be used here. The PaaS solutions usually come with built in repository management mechanisms to help the users belonging to various roles to pick what they want from one environment from another.
For example, when the developer completes the development and is happy with the developer testing on the development cloud, he or she can raise a notification to QA folks indicating the readiness of the application or the service for QA. Then one of the QA folks, respond to the ‘ready for QA’ notification, picks those artifacts from development cloud and promote those to the QA cloud. If the tests fail, tester can demote the artifacts back to development cloud and raise a notification to developers mentioning that it needs more work. If the tests pass, the tester can raise a notification for Dev Ops indicating the service or application has passed QA and ready for staging. The Dev Ops then can promote the QA passed service/application artifacts to staging cloud and inform QA to run and verify automated tests on staging to ensure the service/application is ready to go into production.
Comments