Mimi Potter - Fotolia
Effective DevOps change management for versioning cloud apps
There are many ways to go about versioning your cloud applications, but new approaches may need to be implemented when performing DevOps change management.
Java application versioning and change management traditionally revolved around version-directory tools like git, and configuration/parameter repositories. These have worked well for decades, but come under pressure as businesses demand more agile development practices, and as modern componentization and microservice models for applications emerge. To move Java version and change management traditions to the component-cloud age, organize Java development and testing for component-cloud deployment, use integrated development practices to set up the "Dev" piece of DevOps, and be especially careful of component bindings as they evolve to microservices.
The DevOps change management challenge
The first challenge in versioning cloud applications and DevOps change management for Java is to structure the Java development and deployment environments to be as congruent as possible. DevOps change management can be most easily applied where the testing and production environments are identical. You should not develop and test on bare metal for deployment in the cloud. Don't build your development tools a piece at a time either, from independent elements. It might take a half-dozen different tools to create an application versioning and change management framework for Java this way, and they could be assembled in many different ways.
It's better to adopt a framework for Java development and deployment that's cloud-ready and integrates the necessary versioning and DevOps change management facilities. Red Hat's OpenShift, Oracle's Developer Cloud Service, and other similar products offer IDE support and a framework for Java container deployment that is readily integrated with DevOps tools. They also provide support for containers, the ideal vehicle for cloud execution of Java elements. If the developer environment offers container support and developers can work and test in a mirror of the production environment, then integrating development into application lifecycle management for agile development and continuous delivery is much easier.
Once you have a framework for deployment that's uniform, the critical step is to frame your development processes around a Java-compatible IDE. It's is essential that the IDE integrates version control and change management into the development process by integrating the tools you'll want to use. Absolute consistency is the key here, because you want everything that exits from the development process to present the same level of version/change governance. That lets you carry that standard forward into operations later. The latest version of the popular Eclipse IDE (Che) is such an IDE, and it will integrate most of the versioning and change management features needed directly into the development process, seamlessly.
Development and DevOps change management
Once you have a uniform deployment model for development, testing, and production, and you've established consistent version/change management at the development level, you'll want to use DevOps to extend that model across the operations boundary. That's most easily accomplished by insuring that as much testing as possible, but at the minimum the last stage of development-level integration testing, be done using DevOps deployment of components.
Effective application lifecycle management
To ensure that the progression from development into ALM and deployment is smooth, it's important to frame the Java elements of the application in the way that your preferred cloud deployment supports optimally. Public cloud providers like Amazon, IBM, Microsoft, and Oracle all have Java support and generalized cloud application support. These offer a way of migrating enterprise-specific models like Java EE into a form of "cloud container". When framing your development and testing environment, make sure your Java components are either hosted directly in a suitable cloud container, or are developed in such a way as to make cloud hosting a simple step that DevOps can support. DevOps can configure and deploy containers, and if Java components are given a container relationship that's stable and predictable, then container deployment and integration can be made to map to Java deployment and integration.
All of this prepares you for a cloud application versioning/change management model that frames three "phases" of the application lifecycle. The "development phase" is presumed to be the source of change and the authority for releasing new versions of components. This phase ends with a sandbox that could be called "development integration testing", which is the starting point from which those new versions are released. They are released into the ALM domain, where the purpose of testing is to validate new versions of components and quickly stage them forward. ALM will manage its own sandbox, the second phase in the lifecycle. The ALM processes then stage to the production sandbox from which production deployment takes place. DevOps tools are then created in the development integration testing sandbox to integrate the final development test configuration, then used again to progress through the remaining sandboxes to deployment.
The process described here isn't entirely one of DevOps coordination. As applications develop to a cloud-ready form, they must take on new behaviors such as statelessness, important to make scaling of components and load-balancing across multiple instances work properly. Applications are also more likely to use shared services that are accessed through web APIs, which anonymize the version control inherent in direct Java coupling.
To get this transition under proper control, start by using binding parameter specification in any references to cloud services that are included in Java apps, rather than simply coding a direct reference to a URL and incorporating the parameters without binding references. This can insure that any dependencies on component version are advertised where references to the components are made. That will insure that changes to cloud services are properly tested back against Java components that reference those services.
Remember through all of this that DevOps does not set policies for anything, it enforces them consistently. You'll need to frame your "three phases" of application versioning, change management, and lifecycle management properly within themselves, and systematize the linkage with DevOps, to make your Java apps stable and cloud-ready.
