I'm not sure quite how to phrase this question. I'd like to learn either by answer here or sharing a reference to read from: How do I build a pipeline with versioned build artifact?

I've inherited an established Jenkins build infrastructure that I recognize needs to change. This is especially evident because we want to move into a modern build approach with branches (dev, main, etc.).

This is basically how our builds work

lib-A    is created first
lib-B    is created next
lib-C    is the last library created
prod-DA  uses lib-A
prod-EC  uses lib-C
prod-FAB uses both lib-A and lib-B

Our current build infrastructure is what I'd describe as a dev infrastructure. In that it always uses latest.

When lib's A, B and C are created they are dropped into a shared folder to be used by everyone else.

When prod's DA, EC and FAB need to link with the library they just pull from the shared folder.

This is what I inherited. It's adequate for a single branch, riding-latest build system.

Is there a resource, pattern, book, website or toolset to help me learn how to change this to a versioned artifact scenario? Or how to convert to a mechanism that will scale and support branching?

I don't really even know what to call this, I'm really wanting to learn what you have to share.

Thank you for your patience.

  • I'm a bit new to DevOps myself and it sounds like you may be more familiar with theory than I am but the phrase "a modern build approach with branches" sounds like it may be up for debate. Many of the DevOps resources I've seen recently have suggested moving away from version branches towards direct commit to master. – duct_tape_coder Oct 9 '20 at 17:53
  • As for toolsets, I'm not certain about in Jenkins but with Teamcity you have the ability for one build to leverage (or even be triggered by) the results/artifacts of a separate build process. In this way, a commit to Lib-A could trigger a rebuild of prod-DA and prod-FAB as well. In many cases, this would be automatically run through integration testing and pushed to a test environment. When testing succeeded it could be automatically or manually approved for push to preprod or prod. – duct_tape_coder Oct 9 '20 at 17:56
  • As for versioning, one thing I've seen frequently is reference to tagging. A particular version/environment/etc can be tagged either in VCS or Build system. Build systems will then handle that build according to defined rules for the tag. E.g. integration builds for version X will only pull Lib-A builds tagged with version-x in VCS. – duct_tape_coder Oct 9 '20 at 18:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.