2

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.

Improve this question
3
  • 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, 2020 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, 2020 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, 2020 at 18:01

1 Answer 1

Reset to default
1

I know this question was asked a long time ago but I still want to answer it.

How products are build, versioned and delivered depend highly on the combination of the used tools, the infrastructure and the processes that have been established in your company. This also means there is no general way to it. However there are of course best practices like continuous integration/continuous delivery, nightly builds, common branching patterns etc.

In your case I would start with common branching patterns for the used version control system (svn, git, etc.) and think about how to support versioned artifacts . Next step is to get the build management tool (Maven, Gradle, Make, Cmake, etc.) build the specified version.

If these two parts are working you can think about how to automate it with jenkins.

One last thing: Your question was very general. I guess if you ask more specific questions like "How do I combine maven and git for building versioned artifacts" you get more answers.

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.