We approach this problem from the other end, using Artifactory as the source of truth instead of SVN.
Of course we use SVN to hold our source code, but we never push generated artefacts back to SVN, instead resolved Ivy files are written to Artifactory, see the example below: <info organisation="my-org" module="my-module" revision="4.1.0.34.0" status="approved" publication="20170123114347" ext:svn.url="https://my-source-code/svn/path/to/trunk " ext:svn.revision="12345" ext:qb.id="139450"/> This Ivy file together with the associated artefacts are written to Artifactory. The Ivy file identifies the SVN URL and revision number of the source code, together these allow us to pull the correct source code from SVN when rebuilding the module. In addition the qb.id is a reference into our continuous integration server and can be used to discover additional build specific information. With this setup, you rebuild a module by first locating the relevant Ivy file in Artifactory, next you fetch the source code and any build specific configurations (gleaned from your CI server). Importantly, you MUST replace the original Ivy file fetched from SVN (which is likely to contain dynamic revision constraints) with the resolved Ivy file retrieved from Artifactory which will only contain static revision constraints. This ensures that when you rebuild your module you use the same revisions of dependencies that were used when the module was originally built. The above Ivy snippet is from an "approved" module. In our system this identifies a module that has been built in an approved way, passing all relevant unit tests etc. In order to release a module we must first promote the module to an "candidate" status. When promoting a module we might run additional tests on the binaries, each time these tests pass we update the status of the Ivy file to indicate its position within the release pipeline. We also periodically clean redundant modules from Artifactory by deleting modules with a low status, i.e. modules that may not have passed performance or security tests. When deleting modules it is important not to delete modules that are active dependencies of other modules. You should also be careful not to delete the most recent version of a module in the event that you are generating build numbers based upon a last build number +1 strategy. Jonathan Oulds Snr. Software Engineer McAfee -----Original Message----- From: Marc De Boeck [mailto:mdeb...@gmail.com] Sent: Monday, January 23, 2017 9:09 PM To: ivy-user@ant.apache.org Subject: Re: Performing a release of an IVY module Ivy is a flexible tool and also the release process can be tuned according to your own needs. Personally, I think that you should not try to copy the "release process" used in the maven world. I believe more in a continuous build process where builds are promoted to releases when they have been properly tested. A binary repository manager such as Artifactory can help with this. Here is the build and release process that I propose for Ivy: In the SCM system, dependencies to modules which are part of your "build-project" always have a dynamic revision (latest.integration). Dependencies to modules which are not part of the build-project are specified with a fixed revision. During the continuous build process, a "resolved" module descriptor (aka ivy-file) is published to the binary repository manager. A "resolved" ivy-file means there are no dynamic revisions in it. The related commit in your SCM system is tagged with the name of the build. The status of the resolved ivy-file is "integration". When a build has to be released (according to appropriate own test and acceptance criteria), the resolved module descriptor is retrieved from the binary repository manager, its status is changed to "released", and the module descriptor is published to a "release" repository. Depending on your needs, you can do the same with all its dependencies (the exact revisions are available in the published ivy-files). The corresponding build artifact is then promoted in the binary repository manager. If you are using Git, you can then merge the associated tagged commit into the release branch (this should be a simple forward merge, or else something is messed up in your branching tree). Additionally, you can also tag your SCM-system with the actual release name of your product. That would be the end of the release process. * This process implies that your binary repository manager is as important for your build and release process as the SCM system. So it should be protected appropriately. It is also usefull to setup a batch job to scrub build artifacts which haven't been promoted within a specific timeframe (e.g. one month). * Because builds and tests are done prior to the release process and not afterwards, this release process is much lighter than the maven release process. I am also curious how other people make their releases with Ivy. So feel free to comment and propose alternative release process. Regards, Marc 2017-01-23 20:02 GMT+01:00 <michael.fitz...@bmw.de>: > We are searching for a best practice documentation about the release > process of an IVY module like described here [1]. For us it is quite > important to produce reproducible builds with all dependencies of the > release build. For that, we have to push the resolved IVY descriptor > in the SCM system and create a tag. Does anybody know how this could > be achieved with the IVY system? > > - Resolve dependencies > - Commit descriptor to the SCM system > - Checkout source from the tag > - Do release build and test > - Publish module artifacts > > Thanks > Michael > > [1] Maven release process of modules > http://maven.apache.org/maven-release/maven-release-plugin/ > examples/prepare-release.html > --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.