Hello, We have our CI system setup to build after every commit for verification. It happens to build on a grid with multiple OS's and one of them deploys a snapshot to our Nexus repo. Our QA grabs the latest snapshot of the application at various times and validates the fixes against it. (they look for jira issues marked as resolved - as opposed to closed). This happens repeatedly during the normal development cycle.
Once everything has been validated at least once (new features and bug fixes), then we stage a release build using the Nexus Pro Staging[1] feature. These staged releases are not publicly viewable (but our snapshot repo for OSS is). They will then grab the staged release and do more regression and final verification of that build. This process also repeats but it is intended to converge to a stable release -- the development team at this point has moved on to the next release and only things we deem critical are fixed at this point. We typically restage 1-3 times over a period of 2-3 days. If a staged build is needed again, we just drop the staging repo and restage it. If everything is good, then we promote it and it becomes publicly available. All of this is managed by the staging lifecycle. So to specifically answer your questions: >Does the Nexus dev team ever create a release of Nexus that is meant for >internal purposes only? For instance, do you have a verification team >and if so, how do you distribute a build that you want the verification >team to test? Yes. This is our staged release, but by this point we expect everything is good. We usually find something at this point, but rarely is it a huge issue since everything has already been tested. We use the Pro Staging feature to do this. >I have always thought of SNAPSHOTS as a version that is strictly meant >to track nightly builds or builds between developers. It is, but we operate in an agile fashion so qa is included in the team and they are looking at snapshots as well. This provides us the quickest feedback on fixes during the cycle. [1] http://www.sonatype.com/books/nexus-book/reference/staging.html And a video: http://www.sonatype.com/people/2009/01/nexus-professional-what-is-staging/ -----Original Message----- From: Todd Thiessen [mailto:[email protected]] Sent: Tuesday, April 07, 2009 9:32 AM To: Maven Users List Cc: Guillaume Goulet; Kevin Coupland; Kyle Blaney Subject: Understanding SNAPSHOTS I have been thinking alot lately about SNAPSHOTS and how to best utilize them. I think I perhaps have misunderstood them and I wanted to see what kind of responses I get from the community, particularly from the guys at Sonatype. I took a look at Nexus (which I am using as a good example of a Maven project) to see what kind of versioning it uses. Users of Nexus generally only ever see released versions of it. ie: version 1.2.0.1, 1.2.0.2, 1.3.0 and so on and so forth. Does the Nexus dev team ever create a release of Nexus that is meant for internal purposes only? For instance, do you have a verification team and if so, how do you distribute a build that you want the verification team to test? I suspect your verificaton is done on a SNAPSHOT version, which I believe is one of my big misconceptions of what SNAPSHOTS are meant for. I have always thought of SNAPSHOTS as a version that is strictly meant to track nightly builds or builds between developers. However, now I am not so sure. Is it reasonable to work with a SNAPSHOT in your local repostiory, do a number of unit tests and sanity on that SNAPSHOT and then deploy a version of that SNAPSHOT to your corporate maven repository to share with the rest of the company/community so that they can use it and test against it? A SNAPSHOT is time stamped so a consumer can always know exactly what version they are using. Am I off my rocker? (well, I supose thats a seperate question ;-)) --- Todd Thiessen --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
