3

I'm currently working on a new major version (v2) of an application meant to replace the current production version (v1). This redesign carries with it changes to the front-end, public API layer, internal API layer, and database — the whole kit and kaboodle.

While it is easy to have active v1 and v2 front-ends and public API (which I'll call the "front half" for brevity's sake) simultaneously in our lower environments, for various reason, this is NOT possible for us to do with the internal API and database (which I'll call the "back half").

enter image description here

The v2 redesign necessitates changes to the back half that cause breakage in the v1 front half. However, in this particular instance, by making a minor change in the v1 front half, this breakage can be avoided. As such, it is possible for us to deploy this v1 "shim" along with the changes to the back half to production. When the time comes, we will be able to cut over to the v2 front half without the back half needing any further deployments.

Is there a name for this particular type of deployment, where a shim is deployed to an existing app to make it work with an updated back end, with the goal of making a future cutover seamless?

Taking my definition of blue/green deployment from this informative blog post, I believe this is a distinctly separate kind of deployment.

Improve this question

3 Answers 3

Reset to default
2

... by making a minor change in the v1 front half, this breakage can be avoided.

The above excerpt of this queston reminds me of something similar from around the late 90s, say 1996-1999 (when zillions of ITers were preparing for Y2K ...). In those days, new software releases of huge software vendors would come with release notes that included things like either of these:

  • "this release is to make this software Y2K tolerant " (= allows the software to contnue to work as of Jan 1, 2000, at least for a while, though it would keep showing dates with 2 digits for the year, like 00, and not yet 4 digits, like 2000).
  • "this release is to make this software Y2K ready " (= allows the software to continue to work as of Jan 1, 2000, without any (known) limitation because of the change of century from 19 to 20).

Y2K tolerant softwares would typically also include some sort of magical cut-off value, e.g.: years from 70 (when even MS DOS did not exist ...) to 99 were assumed to be from 1970 to 1999, while anything from 00 to 69 were assumed to be from 2000 to 2069. Such assumption was also why such softwares were required to be superseeded by some Y2K compliant release later on (in which those assumptions were obsoleted).

With the above in mind, the term you are asking for could be something like a "V2 tolerant release", which at some point in the future would then be followed by a "V2 ready release" (= your actual V2 release).

Improve this answer
-2

"Compatibility layer" sounds good to me.

Improve this answer
-2

Perhaps "Zero-downtime live migration"

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.