Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Build promotion: how do you manage dependencies?

I am trying to understand all the implications of switching our java projects from a Snaphot/Release policy to build promotion.

One obvious step is that each build ends up creating an artifact that might be going all the way to the production environment, so there's not Snapshot anymore. But then, how should I manage the link from a project to other artifacts, that may or may not be allowed to go to prod?

I've had a hard time finding valuable information on this particular subject. Of course, build promotion is talked about a lot, but dependency management in the light of a migration to build promotion has less visibility.

I see two choices:

  • One can only depend on artifacts that have been previously promoted to the production environment
  • When one depends on another artifacts, the built artifact can only go to the last environment of its dependencies. That is, if I depend from an artifact that was allowed to go to test and not prod, then my build won't be allowed to go to prod

Are there industry standards regarding this topic? Or best practices?

Thanks a lot for your help :)

edits: We deploy to Artifactory three kind of artifacts:

  • Libraries

  • EARs

  • The modules inside the EARs. Some of those are "public" layers that are needed by any EAR that wants to interact with the currently built EAR

We deploy EARs to JEE servers. Our libraries and public layers are deployed to Artifactory and packaged in the EARs, so they are not directly deployed on the JEE containers.

One project builds several modules, and everything is packaged in an EAR, along with its dependencies. One project can depend on a module of another project and that's where it gets complicated...

like image 204
Sébastien Avatar asked May 02 '18 12:05

Sébastien


People also ask

What is the purpose of build promotion?

Build Promotion allows you to change the status of a build, optionally moving or copying the build's artifacts and its dependencies to a target repository, and setting properties on the promoted artifacts.

What is promoting artifacts?

Promotion is the control of artifacts as they flow up the hierarchy from development to test to production on an IBM® i or z/OS® system. A promotion definition is used with a source and target dependency build definition to move source code, build outputs, and build maps from one level of the hierarchy to the next.

What is promotion in DevOps?

When a promotion occurs, DevOps Center merges the branch from the originating stage into the target stage's branch. It then deploys the metadata from the target stage's branch to the target stage's org.


1 Answers

We distinguish between "deployable artifacts" and "libraries".

Deployable artifacts (like ears, wars, standalone jars) go through a pipeline, so they are promoted and tested in different steps. They cannot be dependencies for any other artifact.

Libraries, on the other hand, are not promoted. When they are built (as a release version), are immediately available as possible dependency for all other artifacts (the release build includes unit tests and some integration tests). They are tested and promoted indirectly when they are used in deployable artifacts.

like image 145
J Fabian Meier Avatar answered Sep 23 '22 03:09

J Fabian Meier