I've recently been implementing a CI system for work. The way I understand maven versions is that it can be of the form x.x.x-y-z. We want to have nightly builds in our CI system and have it tagged as x.x.x-y where y would go up on every nightly build. The next development version would stay as x.x.x-SNAPSHOT. This way our version numbers don't go up like crazy, only the build number does. And we can pick a particular tag and promote it to testing/UAT/production etc.
However, when I try to do a release with the maven release plugin on x.x.x-SNAPSHOT it increments the next version to x.x.x+1-SNAPSHOT. Or I can have x.x.x-y-SNAPSHOT which is quite ugly.
Currently we have a python build script that we use to achieve this, but it is hard to maintain. We want to try to move to a more standardized system that allows us to have nightly builds without having version numbers go up like crazy and still be able to track which version of the code is running on which server.
Is there a way of setting up maven/Jenkins to do what I have described? Is there a better more standardized way to achieve similar functionality?
As a messy solution I am thinking of taking the relevant chunks out of the python script and running them with Jenkins. However, I know there has to be a more elegant way of doing this.
Edit: I'm using maven 3.2.1
Related
If I am working on multiple projects where different Go versions are required to build them, how would I elegantly set up my development environment to deal with this?
Each project has its own Makefile which at some point or the other would invoke Go commands. The issue is that some projects require different versions of Go, but the Makefiles simply use go build. My solution so far has been to simply add whichever Go version I needed to the PATH variable, e.g. project 1 requires go1.12.10, so I just run
export PATH=<path_to_go1.12.10_>/bin>:$PATH
And when I want to build project 2 which requires go1.13.6
export PATH=<path_to_go1.13.6>/bin:$PATH
This works, but is there a more elegant solution? Modifying the projects' build systems is not something I can do, at least not in the short term.
Go build has no native way to set the version to build with, so you are stuck either setting the path like you are now, or executing explicitly using /<path_to_go1.13.6>/bin/go.
For the versions that you implied you are working with, there really should be no incompatibilities between them and the latest version of go. On of Go's tenants is to preserve backwards compatibility under basically all circumstances. You would most likely be better off using go's latest version, and, if something is preventing you from upgrading the compiler, fixing that instead.
I did my build numbers as 1, and then 2.
Does this matter - is it just a mater of preference as to how you do them?
The Build Number (or CFBundleVersion) is not shown in the App Store so for the user it does not really matter.
The purpose of the Build Number is that developers can distinguish different builds using the same Version (CFBundleShortVersionString).
Consider you are working towards a version 2.1.0. Before you publish this version on the App Store, you probably want to distribute Beta builds to testers. If they report any issues and you fix them, you will need to create and upload a new build but probably still use the version 2.1.0. In that case you would use the Build Number to distinguish the two version.
You can use whatever you like as a build version. Apple provides a tool to increase the Build Number in Xcode projects named agvtool.
Another way (and what I personally do) is to use the git commit count as the Build Number. This can be automated via a Build Phase. That way, every change that you make (and commit) automatically increases your Build Number.
Can anyone tell me, if it's possible to add prefixes to the version number when using the maven release-plugin for version-management and releasing? Unfortunately I have no easy way to test it and since I couldn't find anything useful about this topic, I thought why not just ask the SO-community :)
(With prefixes I mean naming something my-service-V10.7.3 instead of my-service-10.7.3)
Basically you can name the released version anything you want (using the interactive mode or the releaseVersion property).
So your build job or whoever calls the release plugin can determine the release version number by itself and hand it to the maven job.
Automatically adding a prefix is not possible
I would, however, advise against using version prefixes. The violate conventions.
Try to go for established version schemes, if you really need to add anything, use 10.7.3.GA or something like that. This will also play nice with plugins and tools that determine which version is newer.
It is around 10 months now that Jenkins split off from Hudson.
When looking at the project homepages I am wondering what the differences between Hudson and Jenkins in the meantime really are. From the changelog I do not realy learn much. There are a bunch of changes and the major difference seems to be that Jenkins releases more often with less changes and Hudson less frequently, but then with more changes in a release.
Are there any notable differences yet?
So are there things that make me as a developer needing a CI system more productive rather with the one or the other?
Is one of them more stable than the other?
Is there any difference yet that has nothing to do with politics around Oracle?
What is the most notable difference from your point of view?
One notable difference is that a big number of plugins moved to Jenkins. While you would still be able to use the old versions with Hudson, the newer versions depend on Jenkins already. Also new plugins are mostly created with dependencies on quite recent Jenkins versions, so you probably won't be able to use them without hassle on Hudson.
This will probably differ from plugin to plugin, some might be more compatible with Hudson than others, while still others provide versions for both tools. But if something does not work well with a plugin you will receive help easier if you use Jenkins.
EDIT: Here is an interesting link I found, not only providing some solid numbers on the different paths Jenkins and Hudson have taken, but also addressing the (non-)issue of IP that was mentioned in the other post here...
check out the work being done on cleaning up the code and the IP checks that are needed to belong to Eclipse Foundation. This is one of the big differentiators if you care about clean IP.
How many plugins are you using? Hudson supports many of the most important plugins independently and is working with plugin owners to keep compatibility with those that are still maintained by their owners at Jenkins.
See the JavaOne presentations that show how Hudson is being maintained and new features added.
https://oracleus.wingateweb.com/scheduler/eventcatalog/eventCatalogJavaOne.do (search for Hudson)
Also check out the Hudson project at Eclipse http://www.eclipse.org/hudson/
I am the Configuration manager for an IT firm. Currently we are using anthill build management server for all our build related purposes. We are looking to implement Continuous Integration in our development life cycle.
Currently the building process is done manually. Suppose there are 5 projects A,B,C,D,E and E is the parent project and the dependency chain does like this:
A->B->C->D->E
What we do is we build A first update project.xml of B to the latest version of A, build B so on and so forth untill all dependent projects get built and finally parent project gets built.
What I am thinking is automating the entire process i.e. automatically finding out dependencies and building them first and then updating the version of parent projects and building them again to a newer version.
Would continuum do this for me? If not is here any other CI tool that does this?
Hudson does this really well, if you're using Maven, it'll even automatically figure out the build dependencies for you automatically after the first build, otherwise you can manually define the build dependencies. I.e., it lets you configure the system to build project B after a successful project A build.
I'm not sure if it matters to you, but Hudson is also open source.
If not is here any other CI tool that does this?
I like TeamCity, which does pretty much everything you'll need. With the latest version (and a plugin from JetBrains), there's even Git support.
On the other hand, any continuous integration system should handle dependencies easily.
We use Zed Builds and Bugs for a setup similar to this. We have a master project that has sub-project dependencies and the build system handles everything in the proper order.
We also have very small, tight builds for the sub-projects so that each of them can be built when the developers commit to source control. The Zed Server is capable of pulling the latest artifacts from these small builds and putting them together into larger builds, but we haven't yet used that feature.
Our check-ins trigger the small CI builds, and then twice per day the entire application is re-built from scratch, following the dependency chain.
I'd agree with OregonGhost, though, any CI system should be able to set up this type of chain.
I don't think you need a CI tool for this. Try to automate this using a buildscript and use Continuum (or any other CI tool) to trigger your preferred buildtool.