pipelines and release vs snapshot builds

Question

I want to use jenkins pipelines for continuous integration, but not cd, I am still using the snapshot and release model of maven. How to cause the pipeline to execute a release build or a snapshot build depending on some condition? Also, how do you trigger some things like testing on other platforms, integration tests, etc only sometimes? I do not want long tests and resource hungry booting on windows to go each time I commit.

Answer 1

One way we do this is based on Branch names. We have release branches in git such as v1.0_release, and we also have integ branches: v1.0_integ.

We setup a multibranch pipeline with a when clause on the branch name. When the branch name is *_release, we deliver that build to the release artifact repo. Other branches go to the snapshot repo.

Anytime any other branch is pushed to git (such as feature branches), they are also built, and depending on the application, we usually just archive these builds in Jenkins. This gives developers quick feedback on any branch they use and easy access to artifacts.

Developers can play with any code in any branches they want, and when they like the code and are ready to build a release candidate, they push to the release branch and Jenkins just takes care of it.

Answer 2

Welcome to the not-so-trivial world of continuous integration. When you use the traditional way of manually triggering builds on the build server, you can choose whether you build

• a SNAPSHOT to play with and show to colleagues
• a release, which should go to production if it passes all the tests.

In pure CI, every commit should be a possible release so the distinction between the above two becomes difficult. You can - and I some people do it - only produce SNAPSHOT builds when doing automatic commit-triggers-build building. Then the builds are only for feedback, but not meant to be used later on. This also makes it easier to delete them when your hard disc complains. In this scenario, you would start the release builds manually.

If you want to be more CI-like, you can consider every commit as potential release and give a release number. Whether you run all the tests is up to you. If your tests take too long, you can tell Jenkins that your automatic pipeline only runs up to a "alpha" level and that the "alpha to beta" pipeline is still started manually if necessary.

Some people will say that you should always run all the tests and keep all the versions, and that hardware is cheap and you could easily build a cluster. These people probably have never seen the inside of large, bureaucratic companies.