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...

    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.

    链接地址: http://www.djcxy.com/p/41566.html

    上一篇: Python多处理的进程通信

    下一篇: 建立促销：你如何管理依赖关系？