Blogging about 97 things

[Steve Berczuk]

I just posted a blog entry about 97 things in case anyone wants to
comment or share it :)

http://steveberczuk.blogspot.com/2010/04/things-about-release-management-every.html

"Things about Release Management every programmer should know"

--
Steve Berczuk | steve....@gmail.com | http://www.berczuk.com
SCM Patterns: Effective Teamwork, Practical Integration
www.scmpatterns.com

[jason...@jegas.com]

Nice Article! (Editor Note: "While I've long be interested in how to build architectures and processes" should probably be "While I've long been interested in how to build architectures and processes") I personally have trouble with version control and recently we had a internal meeting with a soft spoken guest with 25 years of software engineering from Switzerland. She had many recommendations that touched on the topics you mention in your blog). My personal issue is just finding one Source control system that is "accessible" from both Windows and Linux; preferably one that has ways to automate (another thing you mentioned and fancy). Not to date myself - but some of the most reliable source control I used was pre y2K writing visual basic 6 with vb source safe. I know there are much better "backend" systems like cvs and svn that do fancier code merging etc.. but I admit - I found checking files in and out easy, and the colored DIFFERENCE reports made things pretty intuitive for me. Source control is only part of it though - as things complicate when you have various installations (and version) that span both code, files, dir structures, and database models. That's where I sometimes find things admittedly daunting. ...steps off shout box... --Jason P Sage

[Steve Berczuk]

Thanks for the feedback and for catching the typo. Fixed!

If you use a popular open source tool like subversion, you should be able to do most everything from windows and linux. And tools like maven tend to have support for SVN readily available. (not to rule out commercial tools like Perforce... which in particular prides itself on its support or a variety of client platforms).

Database versioning is a tricky thing, since you have many dimensions (DDL, live schemas, and data), so there's a lot one can say about that. A few years ago I co-authored an article on CM Crossroads about those issues... (http://www.scmpatterns.com/pubs/crossroads-mirror/agilejan04.pdf) which has links to resources from Scott Ambler and Martin Fowler.

In terms of support for fancy merging and the like... which such support is useful, it;s sometimes (often?) the case that people think of branching as a solution when you can't keep the codeline working during changes.... doing the latter is more challenging, but often better ;)

Steve

--
To view or edit your contributions, visit http://programmer.97things.oreilly.com
To post to this group, send email to 97things-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/97things-programmer?hl=en
 
To unsubscribe, reply using "remove me" as the subject.

[Greg Colvin]

In my experience the essential use for branching is for fixing bugs in old releases that are still being maintained.

[Steve Berczuk]

We are in violent agreement. I was reacting to the "fancy" branching strategies. 

I have heard arguments tho for Always delivering from the trunk. That would take a lot of discipline and design for supporting old feature sets. 

[Greg Colvin]

The strategies got pretty fancy at Oracle, as I dimly recall.  I never really understood them, but my manager did.  And they got pretty dysfunctional sometimes, with engineers working on code for months with no place to check it in.  I think the problem might have been trying to deliver from trunk ;->