George, Here's my $0.02...
DISCLAIMER: Please take in mind that my comments often lean towards an "ideal" rather than a fully enforced practice due to the constraints of working in reality. :) In 500 words or less (or more), our practices are heavily dependent upon branching and merging for the actual promotion of code between environments. We (try to) use Subversion quite extensively at Hopkins, in chorus with a number of other standard Collaboration and Development Tools (JIRA + Bamboo + Ant + Maven2) for our Continuous Integration and Deployment Management practices. Based on my experience, "true" Continuous Integration is an ideal to aspire towards rather than a perfect practice! That being said... We use branching as opposed to extensively using tags for environmental designations. Our coding practices are somewhere between "The Always-Branch system" [1], "The Branch-When-Needed system" [1], and the "Release Branches" [2] branching pattern. Employing such a methodology obviously means we do quite a bit of merging when it comes time to promote code, but in the long run it seems worth it. (Read: "worth it" to the Release Engineer -- not necessarily to developers who sometimes suffer from Merge-a-phobia [3]!) We use the standard TTB repository format along with the suggested additional "vendor" folder for Vendor Branch Management. Here is an example of our general repository layout and associated environment map, which is honestly ever-evolving: https://foo.edu/svn/<project>/branches https://foo.edu/svn/<project>/branches/<project>-cdoyle <== "LOCAL" developer branch https://foo.edu/svn/<project>/branches/<project>-jdoe <== "LOCAL" developer branch https://foo.edu/svn/<project>/branches/<project>-dev <== "DEV" https://foo.edu/svn/<project>/branches/<project>-test <== "TEST" https://foo.edu/svn/<project>/tags <== contains "PROD" snapshots https://foo.edu/svn/<project>/tags/<project>-1.0.0 <== tagged "PROD" version https://foo.edu/svn/<project>/tags/<project>-1.0.1 <== tagged "PROD" version https://foo.edu/svn/<project>/trunk <== "STAGE" https://foo.edu/svn/<project>/vendor <== container for vendor drops https://foo.edu/svn/<project>/vendor/<project>-current <== "current" vendor version https://foo.edu/svn/<project>/vendor/<project>-2.5.3-GA <== tagged vendor version https://foo.edu/svn/<project>/vendor/<project>-2.6.0-RC2 <== tagged vendor version Environments: "LOCAL" -- Developer-specific branch, typically deployed on a separate locally maintained Tomcat instance. "DEV" -- Shared environment for final Developer testing and sign-off. Sign-off signifies code promotion to TEST. "TEST" -- Environment for Functional and Technical sign-off from Project Managers and End Users on specific issues. Sign-off signifies code promotion to STAGE. "STAGE" -- "PROD-ready" code for testing Production deployments. Pre-production, but treated exactly like a real production environment. Full regression testing indicates promotion to PROD. "PROD" -- Live, from New York... NOTES: - trunk is stable - In a perfect world, there are no discrepancies between what is in the branches and what is deployed on the servers -- hahah!!!! - There is unfortunately no "current" tag to accurately indicate the currently deployed PROD version -- we usually track back to JIRA for that tidbit of info, or assume the highest version number - Merges seem to intimidate some developers who are not familiar with Version Control practices - We use JIRA actions for the sign-off mechanism between environments - I'm a big fan of the "General Vendor Branch Management Procedure" for upgrades [4] Unfortunately, not every developer necessarily cares about Version Control or about this process. I have experienced some internal resistance to even applying simple practices in multi-developer environments. Therefore, enforcement can be an issue, especially if there is no automation in place. Honestly, most of the developers on our team aren't interested in maintaining local development instances of the Portal, so they "share" our Development instance and its associated physical Working Copy on the DEV box (ick!), which in my opinion goes against all the guiding principles behind Version Control. But I digress. I prefer working from my own branch and separate local instance for isolation away from "The Wild, Wild West" that is our DEV box. Okay. The build process. We rely on custom ant "token replacement triggers" for environmental builds by providing a build-time parameter on the command line (-Denv=[local|dev|test|stage|prod]). Using such a mechanism allows us to effectively build for any environment from any Working Copy, so long as the builder has access to the appropriate "key" configuration properties files (whose values are not currently stored in the repository). This is a safegaurd to prevent John Q. Student programmer from having access to PROD (or other) credentials. However, having access to PROD keys could have potentially harmful ramifications if used carelessly, so extreme caution must be exercised when running tasks. (Like, for instance, running "ant -Denv=prod db"...yeech!) I have employed similar environmental build methodologies in smaller subprojects and Portlets using Maven2 "filters", which seems a much saner alternative as a future practice. Unfortunately, most of our processes are still manual at this point. However, I recently hooked our projects up to Bamboo, which handles all the automated environmental builds, notifications, and general CI goodness. It's REALLY nice. "Necessary" might even be a more appropriate word. It's all about automation, communication, and accountability. If someone commits a change that breaks the build, notifications are sent. Awesome, hehe. I have also recently begun trying to use cernunnos as a solution for data migration between environments, particularly between PROD and STAGE, as well as for vendor upgrades. Anyway, for better or for worse, that's where we are at the moment. Hope this helps, or at least encourages further discussion on this topic -- I'm always interested in finding out how everyone else is doing it! Especially Jim from UW-Madison, our resident guru!!! --Chris [1] Subversion Best Practices http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html [2] Common Branching Patterns http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonuses.html#s vn.branchmerge.commonuses.patterns [3] Streamed Lines: Branching Patterns for Parallel Software Development http://www.cmcrossroads.com/bradapp/acme/branching/streamed-lines.html http://www.cmcrossroads.com/bradapp/acme/branching/pitfalls.html#MergePh obia [4] Version Control with Subversion http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html#svn.ad vanced.vendorbr.general > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jim Thompson > Sent: Tuesday, July 31, 2007 6:20 PM > To: [email protected] > Subject: Re: [uportal-dev] Code promotion with subversion > > > Hi George, > > We are facing similar questions - our current processes are based on > CVS. > > We make extensive use of tags, like "test" "qa" "prod" "demo" - which > move > from older to newer revs of files in cvs. The deployment scripts we > run are > driven by these "request" tags - and those scripts also create and > modify > additional tags to keep track of what's where since when. > > One family of tags controls the migration of application files and > another > family controls the migration of uPortal framework files (we use vendor > branches and tags to keep track of releases imported from ja-sig). > > There's a presentation of this here: > https://mywebspace.wisc.edu/jfthomps/vc/IntVCandCM3.ppt > > There are some other links here: > https://mywebspace.wisc.edu/jfthomps/vc/ > > It seems clear that Maven2 and svn are in our future with uPortal 3. > While > we have what seems like a robust and flexible way to handle config > files in > CVS, by using map files, one main question for us seems to be how to > handle > config files in Maven2 and svn. At times we had over a dozen different > environments on-line at the same time, with all updates fully > automated. > > It seems clear that we won't have tags "floating" in svn like we do in > cvs - > and tags are not really at the file level in svn, so we'll have some > adventures with reengineering our processes for svn and Maven2. > > My guess is that I'll no longer be in the business of applying "prod" > tags > to invidual files (which I won't miss). We'll probably have the trunk, > tags > and branches subdirectories in svn under each portlet - and app > developers > will work at that level. Somehow, probably via Maven2, they may create > a > war or zip file when ready to promote an app. I might just be > maintaining > the "inventory" of apps in a pom.xml (e.g., > appX_qa_20070731_1515_MikeF). > Of course we'll probably have a different pom.xml in each environment > and if > we compare, for example, the qa and prod versions, we could see which > apps > have different releases in those environments. > > We hope to reduce the number of config files (maybe 75+ today), but we > probably will still need to deal with the issue of "how to change the > deployed code (e.g., increase or decrease logging level) in environment > X". > > At the moment I can admire the problem, but don't have any immediate > solutions. I hope that we'll get some approaches to the problem and > would > be happly to hear from you if you come up with some ideas. > > Comments? > > Cheers, > Jim > > > George Lindholm wrote: > > > > Hi, > > I'm trying to come up with a process to manage source code > promotion > > from devl to verf to > > production, as well as tracking production deployments (i.e. track > the > > state of the webapps > > directory in svn), both as a way to restore a change and to make > > deployment easier > > across instances/machines. > > > > So I'm wondering what other sites are doing? > > > > Thanks > > > > George > > > > -- > > [EMAIL PROTECTED] ITServices, UBC > > Senior Programmer Analyst > > > > phone: 604.822.4375 fax: 604.822.5116 > > > > > > -- > > You are currently subscribed to [email protected] as: > > [EMAIL PROTECTED] > > To unsubscribe, change settings or access archives, see > > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > > > > > -- > View this message in context: http://www.nabble.com/Code-promotion- > with-subversion-tf4194735.html#a11936245 > Sent from the uPortal - Developer mailing list archive at Nabble.com. > > > -- > You are currently subscribed to [email protected] as: > [EMAIL PROTECTED] > To unsubscribe, change settings or access archives, see http://www.ja- > sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
