In IBM Devops Deploy (IDD), incremental versions are best imagined as a package that contains a miniscule portion of an application that has been changed to implement a feature. During a release, several such incremental versions/packages are deployed to the target environment to deploy the changes. This has been practiced for many years now and is a familiar exercise. Familiarity does not equal simplicity. But familiarity wasn't good enough so tools have evolved to provide features to distinguish packages meant for a release from another release. So, tools added tags, colors, labels and much more to aid the users executing the release to identify versions for deployment. Tools have been trying to solve problems from the lens of familiarity. The above problems do not apply to FULL version in IDD, but it is bogged down by the fact that it is heavier than it needs to be and hence lacks efficiency. So, we introduce Linked version, a new version type in IDD aiming to transform application deployments in mainframe.
Introducing Linked versions in IDD:
Linked versions, as the name indicates, are versions that are interlinked with one another forming a tree like structure, see the pic below. A root version sets off the tree. The root version is the first version (The 1st known state of the application to IDD). Successive versions become direct/indirect versions of the root version.
One way to imagine Linked versions is to think of it as commits in a git repo. You have several commits in a repo. Each commit is a representation of the state of the repo at that point, however a commit doesn't have the entire application, it only has changes committed, yet when you checkout a commit, you get the entire repo as of that commit point. Linked versions behave the same way. Every linked version stores changes packaged in it, whereas referencing rest of the application from its direct or indirect parent versions. For Example, let's say you add features to your application and create a new tag 2.0.0 and a corresponding version V2.0.0 in IDD. When you create the version V2.0.0, you link it as a child to IDD version V1.0.0 and package artifacts that have changed since tag 1.0.0 in your repo. So, here we are packaging only what is changed and not the entire application. Another way of looking at it is, a linked version represents a state of the application.
Tracing to Source Code Manager but efficiently
While we do establish a functionality that resembles GIT, we go beyond by associating commit id with versions as well. When creating a version for artifacts changed in a certain commit, we map the commit id with the version. This brings traceability to your Source Code Manager from the IDD versions.
This kind of versioning gives us benefits not only during packaging but also when deploying. This is because we work with only delta/changed artifacts in both functions. Like we do in packaging, for deployments as well, we deploy only what is needed. Imagine that you have a repo and you want to pull changes from central GIT which is probably a few commits ahead, in this case, only the delta is pulled into your local and not the entire repo all over again. The same happens when deploying linked version as well. We only deploy the delta between what already exists in the environment and what the user wants to deploy.
Reimagining the way the applications can be deployed to mainframes
Similar to GIT repos this allows your environments to be self contained and move away from the standard practice of hierarchical environments. Hierarchical environments served well for the use cases that generated from the capability of the tools offered back in the day. With application packaging and deployment capable of being efficient while maintaining traceability, we pave the way for having self contained environments. For example, Delete-behind or PROMOTE is a practice to keep your environment, version control system and SDLC phases in sync with one another for easier understanding of the software changes in an application. It sure has been successful. However this is an antiquated practice that is indigenous to the mainframe in today's world. This no longer has to be true for mainframes as, with Linked versions, environments can be self contained and every deployment brings the environment to a specific state of the application. The same applies to rollbacks as well. If you have V1.1 and you want to reinstate V1.0 back, you just deploy V1.0.
This new capability is basically telling the tool the desired state of your environment and letting the tool figure out and get the environment to that state. This is good for many reasons, it enables you to version your application not only in your repo but also in your target runtime environment. It also brings straightforward traceability. You don't have to work it out with multiple incremental packages to find out what version of the application your environment is running on. Unlike incremental versions, Linked Version truly represents the version of the application.
With Linked version, we aim to transform and simplify how you can deploy your mainframe applications, and help know your environments.
You can find more about working with linked versions at Linked Versions