Software companies know that their work is never done. This is particularly true for code in managing widely deployed code. Such code must be patched, fixed, and updated, with tools to help move these things through the development process, into various levels of testing and adoption, and finally into widescale deployment.

Automated tools can help organizations work toward continuous integration, which makes the process of patching, fixing, and updating part and parcel of the development, testing, and release processes.

What does continuous integration mean?

Simply put, “continuous integration” means that new code is integrated early and often into the organization’s codebase, and thus becomes subject to inclusion in an automated application build process.

Kiuwan’s Code Analysis (QA) module helps organizations scan and check this code base and foster ongoing analysis and improvement as changes are introduced. This module provides metrics and suggestions for improvement in the areas of:

• Maintainability
• Portability
• Efficiency
• Reliability
• Security

This helps make sure that testing goes more smoothly, and that release channels — developers only, beta test, insider preview, and ultimately, public deployment — work as smoothly as possible.

Multiple builds for multiple channels

Because the Kiuwan tools integrate with big-name IDEs, build systems, bug tracking environments, and code repositories, it becomes more straightforward to keep multiple teams busy on blue-sky development, next-release development, and current version maintenance. At the same time, organizations will work with bug-tracking facilities to keep up with issues that may need patching and fixing in any or all of these release branches and their respective development and QA teams.

The following image shows all the different stops along the way that Kiuwan has covered:

Assigning risk levels and inviting participants in Managing Widely Deployed Code

When it comes to truly large-scale deployments, key user groups, communities, and industry sectors will want to participate in beta testing and possibly also early adoption channels. That’s because they have their own testing to do, to make sure your new releases don’t have adverse impacts or effects on their overall, in-house runtime environments.

It’s important when you set up release channels to assign a level of risk to those channels, so users will know which ones to test most seriously, and to help them plan their own deployment strategies and schedules.

Your blue-sky channel will be of most interest to partners (especially those who develop in or alongside your software) and heavy users who want to provide input and feedback on future features and functions, both those that they see in such releases, and those that they’d like to see (or unsee) in the future.

Your early adopter channel will be of most interest to heavy users, as they test and plan to integrate your next release into their production environment.

But the biggest and most important channel is the one for the current release — or next-to-current release, for enterprise-level users who routinely wait for the latest release to settle down and stabilize before moving over — because it’s the focus for the most (and most focused) maintenance. In this case, some kind of regular patch and update cycle often makes sense (along the lines of “Update Tuesday” aka “Patch Tuesday” at Microsoft, for example.

Out of band is NOT out of mind

It will also make sense to provide warning and perhaps even security info (CVE identifiers, severity levels, and so forth) when security threats or vulnerabilities force the occasional unscheduled patch, fix, or update to be pushed out ASAP. This usually means that potential risk outweighs considerations of convenience and usual schedules, to provide protection against exposures to risk, harm, or loss.