Promotion vs Deployment

More and more lately it seems the topic of promotion versus deployment keeps coming up. What are the differences, and when should I use one versus the other. This is not an entirely straightforward discussion, but we’ll do our best to muddle through it here and clarify this issue.

When you migrate from your existing SCM and build tools, one of the biggest challenges (if not THE biggest challenge) is determining how you’re going to flow your pieces and parts through from development to production. How will you lay out your streams and flow your source changes? At what levels will you build? Where do you need to deploy your outputs? Is the way you’re doing it today an optimal solution you’d like to replicate in RTC, or simply a reflection of your current tooling that you’d like to rework entirely? Understanding how promotion and deployment work and the repercussions of using each will help you make informed decisions and be successful with your migration to RTC.

If you’re quite new to RTC and the enterprise extensions, now might be a good time to jump out and read the Guide for migration to Rational Team Concert for z/OS application development before going any further here. This article will give you some good context and broad understanding of how RTC works for mainframe development.

Aaaaaaand welcome back! First let’s talk about the purpose of promotion, and let’s start the discussion with a picture.

Mainframe development typically occurs in a hierarchy, with changes being made at a development level, advanced through various levels of test and QA (quality assurance), and eventually pushed to production. Promotion is how we flow our artifacts through that hierarchy with RTC. We deliver source changes to a stream in the Jazz repository, and we use dependency build to compile those changes and build our outputs into data sets on the host. We then promote those changes and outputs together up from development to test to QA to production. In doing so, we maintain at each level a collection of outputs that reflect the version of the source at that level, and we avoid unnecessary rebuilds at each level. By promoting, you simply move your tested applications through the hierarchy, rather than rebuilding at each and running the risk of introducing an error and invalidating the test results achieved at lower levels.

So, now that we understand promotion, where do packaging and deployment fit in? Let’s answer that with another picture.

Deployment takes your outputs you’ve built, packages them up into an archive file, copies the archive to a different machine (or a different location on the same machine), and deploys the outputs to a runtime environment (e.g. test, QA, or production). Before deploying the outputs, we make a backup of the data sets that are already there, making it possible to do an n-1 rollback as necessary. You can deploy the same package over and over again to different runtimes, and you can deploy packages in any sequence.

So, what I think confuses people here is that when we talk about “promoting to production” (for example), the data sets we promote to are not actually your production environment. You can think of them instead as your “golden master” production data sets. They live on the machine where you do your builds. They’re not though the copies that are actually “in production.” You can’t rollback a promotion, and you can’t re-promote an output. You would instead package up your production-level outputs that you have promoted to production, and you would use deployment to copy them to your actual production environment.

In summary, generally speaking, you can think of promotion as what you use to keep dependency build properly seeded between levels to avoid unnecessary recompiles. It’s what you use to keep a copy of your outputs at each level that reflect the source at each level. If you’re going to rebuild everything at each level, you don’t need to promote; you can just deliver your source through the levels and run your builds. Generally, you don’t promote your outputs to an environment where they are actually going to be used (test, production, etc). You use deployment for this purpose. Some people do choose to promote to their test environments, but you need to understand if you do this you can’t roll back to a previous level of your modules. You also can only promote to the environment one time. You cannot re-promote an output like you can re-deploy your package. Understand also that deployment allows you to simplify your hierarchy. You may currently be pushing your changes from development through six different test levels and then up to QA, where really those various test levels just reflect different environments you need to deploy to for test. Our ability to re-deploy a package to all of these environments eliminates the need for these levels in your hierarchy.