An LTS build is a stable build that should be supported for a longer than average period of time. This can be an important issue for some organizations because moving to a new version of software can pose several challenges, including
Time, effort, and money to ensure that the new version performs within standards.
Potential new licensing costs.
Having to deal with potential inconsistencies or incompatibilities. For example, a newer version of software might not integrate with other software that the organization is already using.
Additional training costs to teach existing employees and customers how the new version of the software behaves.
Reduced production as employees attempt to use the new version of the software.
One disadvantage of utilizing an LTS build is that new features that are released with the regular stable build are not normally implemented in the LTS build.
You may have heard how miners would take a canary into the mines with them to determine if the air held dangerous levels of toxic gases. The idea was that the bird had a faster breathing rate than humans and would show signs of the presence of toxic gases sooner than humans would.
A canary release works on a similar concept. New features are released to a specific set of beta testers to determine if the new features have any negative impact on the software. The features are provided in the new beta builds in a very specific manner and typically spread out over several beta releases. This allows the developers some insight as to which new features may have caused an issue and allows the developers the time to fix the issues before releasing the software in a stable build.
The following sections describe different upgrade methods that your organization may incorporate when upgrading resources in the cloud.
Rolling upgrades (also called continuous delivery) is the process of frequently providing updates to software. With this upgrade method, there are not specific release points (although it is common for rolling upgrades to happen nightly), but rather when the developer is ready, a new upgrade is released.
One advantage of a rolling upgrade is that new features are more rapidly released to customers. However, rolling upgrades may be more susceptible to bugs.
Most developers that provide rolling upgrades also provide traditional “release point” upgrades. For example, the popular web browser called Firefox provides a nightly rolling upgrade, but it also provides regular standard releases.
An active-passive upgrade is similar to using a blue/green deployment. With an active-passive upgrade, the upgrade is deployed to the active environment and the passive environment is not changed.
If any problems occur in the active environment because of the patching, the passive environment is treated temporarily as the active environment. When the problems are worked out in the original active environment, the original passive environment is again treated as passive, and the original active environment is used again as the actual active environment.
If, after testing and a specific period of time, the active environment seems to be functioning properly, the patch is applied to the passive environment. This is different from a blue/green development environment in which the two systems “flip flop” between upgrades as active and passive.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
