There are as many ways to versioning, building, continuous integration and release management as there are development shops, however there are some best practices and luckily these best practices also have tool support.
First the players
| Versioning | Handles the source code versions, also includes branching. Could be an old one like CVS or a newer one like SVN or Git |
| Building | Turns the source code into a deployable artifact, sometimes simply exporting from eclipse, but Ant and Maven are two script based build tools. |
| Continuous Integration | Pulls the source code as it is checked in and runs the build against it, optionally this can include deploying the built artifact. Detects build errors introduced by checkins. Examples include Jenkins and buildbot. |
| Release management | Contains the in development (not intended for QA or Production often called snapshots) and release versions of deployment artifacts and their binary dependencies. Examples include artifactory and nexus. |
Here is how they work together
Review of the typical tasks
Developer build
Developer fetches/syncs the code with the version control system, which also contains the maven build script. They can work as they normally do in rad/eclipse to add/update the source files. There is a maven plugin which tries to convince eclipse to use maven style conventions mostly it works but it isn’t perfect. In the maven build file the dependencies of the project are listed, these dependencies may be internal dependencies such as an internally developed library or could be external dependencies such as the Spring library. When these dependencies are listed both the name and the version are listed to ensure correct resolution. Any dependency listed that isn’t already available locally will be fetched from the nexus repository before the compile is done.
One very important trait of this is that the on a fresh new developer/build machine simply issuing “mvn build” will automatically download and installed all that is needed for a new compile. Setting up a working development workspace couldn’t be easier, but this has a dual purpose it is also how the continuous integration can be made to work so easily.
Developer checkin
The developer checks in their changes by any normal mechanism they choose, they can use the eclipse plugins or command line. Jenkins sees the update, it checks periodically, and fetches the updated files. Then it runs the maven build file in the project, any dependencies which are not already stored locally are fetched (if the developer added a new dependency for instance) and the build is done.
Now optionally you can also do a deploy once you have the new artifact to a development server. Jenkins doesn’t really do much to help you in this, you have to write the scripting for the deploy yourself and will likely vary project to project, however you can configure it to be done after any successful build.
You can also configure Jenkins to send e-mail to whomever was responsible to the checkin that broke the build.
Development release
Remember how I said maven dependencies are based on name and version, well during development a project you may have some developers working on a shared library and others working on a portlet that depends on it. However, the portlet developers may not want their code constantly being broken by API changes. For this there are SNAPSHOT releases, versions of a library meant to be distributed to other developers, but not for release. So the portlet developers can work along on version SNAPSHOT.01 until such a time as they are ready to switch to SNAPSHOT.02.
To do a snapshot release the developer simply runs “mvn deploy”, the maven script then checks out the project, builds it, pushes the built artifact to nexus
Production/QA release
A release is a little different than a day to day development build, the process is a little more complex but the command is just as simple “mvn release”. This checks out and builds the project, updates the version in the maven build file to a RELEASE then checks that back into version control, lays a tag indicating the release number in version control and then finally pushes the file to nexus.
Now deployments should instead rely on the releases stored in nexus not on files sent in an e-mail or stored on a network share. You can even optionally configure security so that only some users/processes can actually do a release.
