Java DevOps provides Agile path to continuous delivery success

Limited Time Offer!

For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!

Enroll Now

Source – theserverside.com

Every enterprise wants to make IT more responsive to user needs, and at the same time make development and deployment more efficient and fail-safe. Java is the most popular programming language, and it offers much to support these goals. The challenge is making all the various strategies work together. To do that, divide Java projects and continuous delivery capabilities by stage of impact, explore state-of-the-art approaches in each stage, and use project-level practices to tie all the pieces together.

At the high level, the goal of most modern software advances is the concept of continuous delivery, meaning a process of software creation and enhancement that makes refinements available immediately without sacrificing development efficiency, compliance/governance, and operational stability. Continuous delivery is really the sum of three separate focus areas; team development, continuous integration, and integrated deployment.

Java DevOps and continuous delivery

The most important truth about continuous delivery is that you can’t apply it to code by simply changing the way you collaborate, integrate, or deploy. Continuous delivery with Java DevOps demands software architecture discipline to be fully effective. Software modularity, process automation, use of design patterns, and development of features as services and microservices are crucial in creating software that can be optimized for delivery; from there you can get on to the steps associated with doing that optimization.

To make continuous delivery and Java DevOps work, you not only have to understand the concept behind it, but you have to be able to atomize feature development so that incremental improvements in software can be generated quickly and then integrated into a form that can be released. Release testing and control is traditionally done by having a series of test-and-integration phases through which code advances, but this requires grouping changes and introduces long delays. Continuous delivery has to allow for continuous integration, meaning that feature changes have to be managed so that they can be tested with other code and released on a per-feature level when ready.

Java DevOps and feature enhancements

This kind of endless, asynchronous, feature development and release is an invitation to disorder. To insure you don’t lose stability along the way, the Java DevOps notion of feature flags or toggles is important. These allow the development and testing state of individual features to be reflected in the code itself, which means that a release can “turn off” a given feature or version if it’s not ready, yet keep the code available for integration testing. This brings continuity to what’s otherwise a classic version-control release problem. You can see that if feature flags are to be inserted in code, it’s important not to mix too many features/functions in a single unit of development. Service-based architectures tend to enforce a reasonable level of modularity, which is why the architecture of your Java app is important.

All this demands harmony in the software development and build library support. You don’t want multiple phased repositories with multiple versions in a continuous delivery environment. You want a single library with per-feature change control. GitHub is a popular library and there are a number of good tools that work from GitHub to control integration, including Travis and GetLib CI. Users report that it’s easier to implement continuous integration if the team works through a common IDE, and so converging on a library and IDE is a good first step.

If feature flags/toggles are important then managing how they’re used is also important. There are specialized tools available for this; LaunchDarkly is well-regarded for feature flag control, and it also provides other continuous integration features. Split is also a good choice; it makes visualizing the relationship between flags and team activities along the road to delivery much easier. Togglz, which has good support for the popular Eclipse IDE, is a good open-source framework for feature flags that offers perhaps more control though not as elegant an interface.

The importance of Java DevOps

Delivery, or more precisely the “delivery” part of continuous integration and delivery, is normally a responsibility of DevOps. The obvious issue in continuous deployment is what gets deployed, meaning how a correct feature set is selected. When staged testing and deployment was the rule, application lifecycle management processes normally controlled the development-to-deployment progression, but continuous delivery complicates that.

You can, in theory, use feature flags to turn features on and off at runtime, or to turn off their deployment. The former is probably the preferred model, since flag-controlled staging for deployment doesn’t move the ball much from version-controlled deployment. The run-time use of feature flags has a significant benefit in that the deployment model that DevOps tools work from is essentially constant. The disadvantage is that improper use of feature flags will almost certainly result in contaminated deployments and instability. If you plan to use run-time control of features to simplify your DevOps model, then plan on having specific tools to manage the flags.

There is a significant but not majority view that continuous integration is easier to deploy using the prescriptive tools than the descriptive or declarative Java DevOps tools, which can lead to a scripts versus model states discussion. It’s probably true that traditional release control phases and ALM are more easily managed with model-driven DevOps because the phases of ALM are easily mapped to different models. What does seem to be true is that some kind of development-and-runtime flagging of features can ease the “Dev” to “Ops” transition considerably no matter what tool you pick.