Developers' Best Practices » History » Version 1
Alessia Bardi, 09/01/2014 07:12 PM
1 | 1 | Alessia Bardi | h1. Developers' Best Practices |
---|---|---|---|
2 | |||
3 | It is time for D-NET development teams to find a strategy to improve our developement work! |
||
4 | |||
5 | The introduction of Jenkins and Nexus helped a lot in terms of code management, but now it is time to establish a set of guidelines to better co-ordinate our teams. |
||
6 | The following best practices are inspired by CNR developers' common sense, so we do not assume they are written in stones and applies as they are also in your cases. |
||
7 | |||
8 | So, you are strongly invited to comment/update this wiki page, so that we can reach a consensus. |
||
9 | |||
10 | h2. Branching |
||
11 | |||
12 | It is always recommended to create a new branch when performing heavy changes to a module, rather than directly into trunk. |
||
13 | |||
14 | h2. Trust Jenkins: Use CI! |
||
15 | |||
16 | The developer should clean the @.m2/repository/eu@ local repository from time to time to be sure that there are no modules installed locally. |
||
17 | |||
18 | Modules should be downloaded from Nexus in order to properly resolve dependencies. |
||
19 | |||
20 | h2. Release Best Practices |
||
21 | |||
22 | h3. When/Why releasing a module? |
||
23 | |||
24 | * Generally speaking a developer should release a module when the code is mature enough to be used by others. |
||
25 | * An early release should be available in case others are relying on a module that is currently under heavy development (i.e., frequent commits that imply frequent snapshot updates), in order to avoid blocking other development activities. |
||
26 | * Before updating an interface (e.g., service interfaces) or library (e.g., common and utilities modules) a developer MUST ENSURE there is a release of the current version. |
||
27 | |||
28 | h3. How to assign a release version number? |
||
29 | |||
30 | Before releasing a module, you must check which kinds of changes have been performed since the last release. |
||
31 | @svn log@ is your friend here :) . |
||
32 | Depending on the kind of changes you can decide to increase the artifact version according to the following guidelines: |
||
33 | * BIG CHANGES impact the MAJOR version number. Ex. @0.0.1 --> 1.0.0@ |
||
34 | ** Examples of big changes are: updates to service interfaces, shared libraries, new functionalities. |
||
35 | * MINOR CHANGES impact the MINOR version number. Ex. @1.2.5 --> 1.3.0@ |
||
36 | ** Examples of minor changes are: service internals, non-shared code and libraries, important bug fixes. |
||
37 | * BUG FIXES impact the BUILD version number. Ex. @1.4.2 --> 1.4.3@ |
||
38 | ** Examples are small bug fixes that do not affect other components |
||
39 | |||
40 | h3. How to release? |
||
41 | |||
42 | These are the steps for the release of a module, given that developer has a fresh checkout of the module to be released. |
||
43 | |||
44 | # Ensure that the module to be released and the modules depending on it compile fine on Jenkins (http://ci.research-infrastructures.eu/). |
||
45 | # Update and commit the version of the module (trunk) to be released according to the guidelines above. |
||
46 | This maven command can be helpful: |
||
47 | @mvn versions:set -DnewVersion={release_version}-SNAPSHOT@ |
||
48 | # Copy the trunk source code to a release branch: |
||
49 | @svn cp https://svn.driver.../modules/<MODULE_NAME>/trunk https://svn.driver.../modules/<MODULE_NAME>/releases/{release_version}@ |
||
50 | # Switch to the release branch: |
||
51 | @svn switch https://svn.driver.../modules/<MODULE_NAME>/releases/{release_version}@ |
||
52 | # A released module MUST depend and inherit ONLY from released modules. Therefore the pom.xml file MUST be updated as follows: |
||
53 | ## change the parent version to a released version. Current is 0.0.1-alpha. |
||
54 | ## change all snapshot dependencies to a released version. Ex. @0.2.3-SNAPSHOT --> 0.2.3@ |
||
55 | ## change the artifact version by removing the @-SNAPSHOT@ suffix. |
||
56 | # Commit the updated pom.xml. |
||
57 | # Ensure the module compiles: @mvn clean compile package -U@ |
||
58 | # Create the release build job on Jenkins (http://ci.research-infrastructures.eu/): |
||
59 | ## Select "New job" |
||
60 | ## Type in the name of the job as |
||
61 | @[module name]-release-[version]@. Ex. @dnet-runtime-release-0.0.9@ |
||
62 | ## Select "Create from existing job" and type in @dnet-svn-template-release@, then press OK |
||
63 | ## Modify the repository URL so that it matches the svn folder of the release branch |
||
64 | ## Save, enable the job, start the job, watch it compile, ensure it is deployed on nexus, disable the job again (an artifact on the dnet-release repository cannot be overwritten, hence we disable the job just to be sure they are not fired again by mistake). |
||
65 | |||
66 | Possibly a script will be made available to cover the points from 2 to 7. |