4

Java artifacts are often staged through different "quality levels", named like alpha, beta, releaseCandidate, release etc. They enter the next stage if they have passed tests (automatic or manual ones).

We have an old, primitive staging software in our company. This should be replaced. Before we opt for getting some existing software, or writing something new we want to understand the topic more thoroughly. The first question for me is: Is the build server the right place to handle staging?

The build server already handles a number of steps like compiling, unit-testing, packaging etc. These steps finally deploy an artifact to our company repository. Implementing staging would mean that after that first deployment, the process would be halted, and one could manually trigger further stages, which again would lead to deployments.

Or should the staging be done in an Artifact Repository, pushing artifacts from one subrepository to another?

To make things clear: The part I am mainly interested in is the manual process of pushing artifacts from one stage to the next, usually after manual testing. It is important that the artifact is already in the Artifact Repository before it enters the final stage, e.g. beta versions are available from the Artifact Repository, but a manager can promote beta versions to release versions.

Improve this question
3
  • Possible duplicate of Responsibilities of Build Script and Build Server
    – gnat
    Apr 28, 2017 at 11:18
  • This does not seem to answer my question which is mainly about staging and not about having a build server. I have added explanation to my question.
    – J Fabian Meier
    Apr 28, 2017 at 11:25
  • Our current setup is not unlike this: CI checks out the commit, runs unit and integration tests, saves the built artefacts, downloads the artefacts again (so we know they're the built and saved versions from the repository) and deploys to an acceptance environment. Then we have pipelines we can run to deploy those same artefacts to any of other other environments (staging and production).
    – jonrsharpe
    Apr 28, 2017 at 15:59

1 Answer 1

Reset to default
-1

Rather than thinking of a multi-level stages just limit it to two.

  • Release - something that when put in the artifact repository it should not change without having a new version
  • Snapshot - something that can change over time or even disappear (once the release is made)

As for release there's no reason why you can't have release versions with a suffix of .Alpha .Beta .Stable

A lot of this work can be done with the Maven release plugin (though its not trivial to understand and setup especially for less painful version control systems)

That being said to answer your more specific question about having multiple servers. It is all up to you and your rules. I would recommend having one public one or even use Maven central if it is open source. Sonatype OSS provides a nice guide to set it all up and I use it for my own projects.

However, you're in an enterprise setting so I would say one enterprise wide server for anyone in the enterprise to use and consume and one staging one. This will divide the load between release server and staging server. The releases will have the alphas and what not since they're releases anyway unless they are still being updated in which case they go to the snapshot server.

And I would likely recommend you set up release server to hook up as a proxy to central as well so you can limit the amount of external network traffic from your enterprise.

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.