Showing posts with label Version-Control. Show all posts
Showing posts with label Version-Control. Show all posts

Tuesday, July 14, 2009

Mercurial, Git and Scala

Three more brand new books I just received that are worth mentioning ...


For those who may not know ...
  • Mercurial (like Git) is an open-source, distributed version-control system.

  • While Scala is the "hot" new JVM-based programming language that not only contains the "best of both worlds" from other statically-typed languages (like Java) as well as dynamic languages like Groovy, but also the best of both worlds from object-oriented programming languages (OOPLs) and functional programming languages (like Erlang and Haskell). Plus it has message-passing and actor-based support for concurrency (like Erlang) while still being strongly typed and having access to all your favorite Java APIs (and anything else that compiles to JVM). Not too mention that Scala has a kick-butt Web development framework called Lift that is a next-generation framework to the likes of Rails/Grails and Apache Struts.

Scala is my first pick for the programming language that is most excitingly poised for the multi-core programming revolution in the age of multicore processors, cloud-computing, web 2.0 and access to all your favorite Java APIs/apps.
Posted by at No comments:
Labels: , ,

Thursday, May 21, 2009

Synchronous and Staged Integration

I participated in a LinkedIn CM group discussion about Building Code before -vs- after Checkin. The discussion was kicked-off by Tracy Ragan, COO and Co-Founder, OpenMake Software:

Many companies implementing a distributed SCM process make the mistake of checking source code into their SCM repository before they validate the code through a compile and link process. Checking in source code that does not compile is honestly, a waste of time. I call it the garbage in/garbage out method. The goal of SCM is to match your production source code to your production executables. This goal should be kept in mind when implementing your SCM process.

So many companies have a very complex SCM process with tightly managed approvals. But when it comes time to roll out binaries to production, they have no idea how those binaries were created. What you need is the ability to run a footprint of your production executables showing all artifacts used to create those binaries. That footprint should show the versions of the files that were found via your SCM repositories and audit all files that were used to create the binary but were not stored in your SCM repository.

Build your code as part of your SCM process. This is the only way to know if the code you are spending time and money to manage is actually executing in your production environment. The mainframe community has gotten this right for the last 20 years. It is time for the distributed developers to sort out a 100% complete SCM process.

There were several good comments, most of them tacking positions for or against, and a few adding some more insight. I responded as follows ...

I wrote a paper for the CM Journal on this very issue a few years back (Nov 2003). It was entitled Codeline Merging and Locking: Continuous Update and Two-Phased Commits

It talks about what we ideally want to have done by the time we try to commit our changes to the codeline (shared/team integration branch) and some of the different strategies (patterns) and trade-offs for how to ensure correct, complete & consistent results while still trying to be as practical as possible regarding complexity and overhead.

It does not however discuss the issue of "synchronous" versus "asynchronous" build+regression-test as part of the commit operation. It assumes "synchronous", where you must successfully build+test *before* the commit operation is considered complete (which is what Tracy is talking about here).

Another approach is "asynchronous", which is what many CI-server implementations do: allow the commit complete (perhaps after doing only an incremental build), but then behind the scenes immediately "kickoff" a more rigorous/complete build which then raises a visible alert upon failure (which should then be fixed *immediately*).

Rather than an either/or approach (building before commit -vs- building after commit), what is becoming more common for larger projects & codebases is a "staged continuous integration approach" such as those described by the following:
Posted by at No comments:
Labels: ,

Thursday, June 19, 2008

Four Rules for Simple Codelines

Some of you may be aware of Kent Beck's Four Rules of Simple Code that state simple code:
  1. Correctly runs (and passes) all the tests
  2. Contains no duplication (OnceAndOnlyOnce and The DRY Principle)
  3. Clearly expresses all the ideas/intentions we needed to express (reveals all intent and intends all it reveals)
  4. Minimizes the number of classes and methods (has no superfluous parts)
(I've seen some boil this down into some of the same rules for writing clear prose: correct, consistent, clear, and concise.)

Lately I've been noticing some parallels to the above and rules for what I would call "simple codelines" and I think there may be a similar way of expressing them...

Simple codelines:
  1. Correctly build, run (and pass) all the tests
  2. Contain no duplicate work/work-products
  3. Transparently contain all the changes we needed to make (and none of the ones we didn't)
  4. Minimize the number and length of sub-branches and unsynchronized work/changes

To elaborate further...

Correctly build, run (and pass) all the tests

This is of course the most obvious and basic of necessities for any codeline. If the codeline (or the "build") is broken, then integration is basically blocked, and starting new work/changes for the codeline is hindered.

Contains no duplicate work/products

The same work and work-products should be done OnceAndOnlyOnce! Sometimes effort is spent more than once to introduce the same change/functionality. This is sometimes because of miscoordination, or simply lack of realization that what two different developers were working on required each of them doing some of the same things (and perhaps should have been accomplished in smaller chunks).

Other times, rather than modify or refactor a common file, some will simply copy-and-paste the contents of one or more files (or directories/folders) because they don't want to have to worry about reconciling what would otherwise be merges of concurrent changes to the common files.

This is akin to neglecting to refactor at the "physical" level (of files and folders) as opposed to the "logical" level of classes and methods. It adds more complexity and (over time) inconsistency to the set of artifacts and versions that make up the codeline, and also eventually adds to the time it takes to merge, build, and test any integrated changes.

If content is being added to the codeline, we want that content to have to be added only once, without any duplicate or redundant human effort.

Transparently contains all the changes we needed to make (and none of the ones we didn't)

The above is sometimes the cause of much undesirable additional effort that is imposed for the sake of attaining traceability and ensuring process compliance/enforcement. Here, I mean to focus on the ends rather than the means, and I say transparency rather than traceability for that very reason.

If people are working in a task-based and test-driven manner, it should be simple to report what changes have been made since a previous commit and that only intended tasks were worked-on and integrated.

If a codeline is truly simple, then it should be very simple and easy to reveal all the changes that went into it without adding a lot of overhead and constraints to development. It should be easy to tell which changes/tasks have been integrated and what functionality and tests they correspond to. One very simple and basic means of tying checkins (or "commits") to backlog-tasks and their tests can be found here; others are mentioned in this article.

Minimizes the number and length of sub-branches and unsynchronized work/changes

Branching can be a boon when used properly and miserly. It can also add a heck of a lot of complexity and redundancy for maintaining two or more evolving variants of the project. The additional effort to track and merge and build many of the same fixes and enhancements in multiple configurations can be staggering.

Sometimes such branches are useful or even necessary (and can help with what Lean calls nested synchronization and harmonic cadences). But they should be as few and as short-lived as possible, preferably living no longer than the time it takes to complete a fine-grained task or to integrate several fine-grained tasks.

Even when there are no sub-codelines of a branch, there can still be un-integrated (unsynchronized) work-in-progress in the form of long-lived or large-grained tasks with changes that have not yet been checked-in or synced-up with the codeline. Keeping tasks short-lived and fine-grained (e.g., on the order of minutes & hours instead of hours & days) helps ensure the codeline is continuously integrated and synchronized with all the work that is taking place.

Another (possibly less obvious form) of unsynchronized work is when there is a discrepancy between the latest version of code checked-in to the codeline, and the latest version of code that constitutes the "last good build." Developer's lives are "simpler" when the latest version of the codeline (the "tip") is the version they need to use to base new work off of, and to update their existing workspace (a.k.a. "sandbox").

When the latest "good" version of the codeline is not the same (less recent) than the latest version, it can be less obvious to developers which version to use and become less likely that they use/select it correctly. Some use "floating tags" or "floating labels" for this purpose where they "move" the LAST_GOOD_BUILD tag from its previous set of versions to the current set of versions for a newly passed/promoted build. Sometimes the developers always use this "tag" and never use the "tip" (except when they have to merge their changes to the codeline of course).

Even with floating tags however, it is still simpler and more desirable when the last good version IS the latest version. Even if the latest version is known to be "broken", the lag between "latest" and "last good" version of a codeline can be a source of waste and complexity in the effort required to build, verify and promote a version to be "good" (and can introduce more complexity when having to merge to "latest" if your work has only been synchronized with "last good").

Plus, this lag-time often leads many a development shop to separate merging (and integration & test) responsibilities between development and so called integrators/build-meisters, where the best developers can attempt is to sync-up their work with the "last good build" and then "submit" that work to a manually initiated build rather than being directly responsible for ensuring the task is "done done" by being fully integrated and passing all its tests.

Such separation often leads to territorial disputes between roles and build/merge responsibilities. This in turn often leads to adversarial (rather than cooperative and collaborative) relationships and isolated, compartmentalized (rather than shared) knowledge for the execution and success of those responsibilities.

So there we have it! Four rules of simple codelines.

Simple Codelines should:
  1. Correctly build, run (and pass) all the tests
  2. Contain no duplicate work/work-products
  3. Transparently contain all the changes we needed to make (and none of the ones we didn't)
  4. Minimize the number and length of sub-branches and unsynchronized work/changes

Sometimes there are legitimate reasons why some of the rules need to be bent, and there are important SCM patterns to know about in order to do it successfully. But any time you do that, it makes your codeline less simple. So you want those scenarios to be few and far between, and to keep striving for the goal of simplicity. (Other SCM patterns, such as Mainline, can help you refactor your codelines/branches to be more simple.)
Posted by at No comments:
Labels: , ,

Monday, June 02, 2008

The Laws of Codeline (Thermo)Dynamics

Some of the discussion with my co-authors on our May 2008 CM Journal article on Agile Release Management spurred some additional thoughts by me that I hope to refine and work into a subsequent article later this year.

Release Management is about so much more than just the code/codeline (and it being "shippable") it's not even funny. Some other articles to reference and mention some key points from are:
Kevin Lee has written some GREAT stuff on Release Management that relates to Agile. The best is from the first and last chapters of his book on "The Java™ Developer's Guide to Accelerating and Automating the Build Process" but bits of pieces of it can also be found at:

ANY discussion about Release Management also needs to acknowledge that there is no single "the codeline", not just because I may have different codelines (Development-Line plus Release-Line) working toward the same product-release, but ESPECIALLY because no matter how Agile you are, the reality is that you will typically need to support MULTIPLE releases at the same time (at the very least the latest released version and the current under development version, but often even Agile projects need to support more than one release in the field)

So, when dealing with multiple release-line, and any "active development lines" for each of those, and the overall mainline, we really should say something overall about how to manage this "big picture" of all these codelines across multiple releases and iterations:
  • What is the relationship between development line, release-line and release-prep codeline?
  • How do the above three "lines" relate to "mainline"
  • What is the relationship between the different release-lines for the different supported releases
  • What is the overall relationship between the mainline and the release-lines (and if the mainline is also a release-line, which release is it?)
The above questions and the ability to give some big picture "advice" on relating it all together (the stuff of pattern languages) is precisely where Laura Wingerd's writing on "channeling the flow of change" and her chapter on "How Software Evolves" fits in! It tells us
  • The overall Mainline model
  • The different types of codelines ("line" patterns), and what kinds of builds take place on each of them
  • The relationships of those to the mainline
  • When+Why to branch (and from which "types" of codelines)
  • When+Why to merge across codelines (as a general rule)

These are where Laura's rules for "the flow of change" apply. And her concept of "change flow" is very much applicable to the Lean/Agile concept of "flow of value". The Tofu scale and "change flow" rules/protocol have to do with order+flow of codeline policies across the entire branching structure when it comes to making decisions about stability -vs- speed. One codeline's policy might make a certain tradeoff, but it is the presence of multiple codelines and how they work together, and how their policies define the overall flow of change across codelines, that forms the "putting it all together" advice that is key to release management across multiple releases+codelines.

In some way's you could make an overall analogy to the Laws or Thermodynamics and the realities of codeline management. Software and codelines tend, over time, to grow more complex and, if unchecked,
"Entropy" (instability) quickly becomes the most dominating force to contend with in their maintenance. See

The "entropy" (instability) doesnt just happen within a codeline. It can actually get far more hideous when it happens across codelines via indiscriminate branching from, or merging to, other codelines. This is what happens when you don't respect the principles and rules of "change flow" (from Wingerd) which ultimately stem from the rules of smooth and steady (value-stream) flow from Lean.

The Laws of Thermodynamics are about energy, entropy, and enthalpy. In the case of release management and codelines ...
  • energy relates to effort & productivity
  • entropy relates to stability/quality versus complexity
  • enthalpy relates to "order" (i.e., in the sense of structure and architecture as Christopher Alexander uses the term "order"). It is the "inverse" of entropy.

We could call them them "Laws of Codeline Dynamics" :-)

Energy misspent degrades flow, creates waste, and hurts productivity/velocity. In traditional development, we often see "fixed scope" with resources and schedule having to vary in order to meet the "scope" constraint. IN Agile development we deliberately "flip" that triangle upside down (see the picture in the article at here under the title "The Biggest Change: Scope versus Schedule - Schedule Wins"). So we are fixing "resources" and "schedule" and allowing scope to vary.

This might be one way of viewing the law of conservation of energy. If we fix resources and time (and insist on "sustainable pace" or "40hr work week") then we're basically putting in the same amount of effort over that time-box, but the key difference is how much of that effort results in "giving off energy" in the form of waste ("heat" or "friction") versus how much of that energy directly adds value. Both "Value" and "Enthalpy" degrade or depreciate over time, and adding more energy (effort) doesnt necessarily mean value is increased.

To make sure that energy goes toward adding value (and minimizing waste) we need to focus on the flow of value, and hence the flow of change/efforts to create value (the latter is one reasonable definition of a "codeline" or a "workstream"). to ensure a smooth, steady, and regular/frequent flow, there are certain rules we need to impose and regulate stability within and across codelines to better manage all those releases.

Zeroth Law of Thermodynamics (from Wikipedia)
- If two thermodynamic systems are each in thermal equilibrium with a third, then they are in thermal equilibrium with each other.
Translation to codelines ... this law of "thermal equilibrium" is a law of "codeline equilibrium" of sorts. (Does this mean If two codelines are are "in equlibrium" with a third codeline, then they are "in sync"? and with each other? here "in sync" doesnt mean they have the same frequency, it means their is some synchronization pattern regarding their relative stability and velocity. In Lean Terms, this would refer to "nested synchronization" and "harmonic cadence"). This might imply the "mainline" rule/pattern or one of Wingerd's rules of change-flow.

First Law of Thermodynamics
- In any process, the total energy of the universe remains the same.
This is the statement of conservation of energy for a thermodynamic system. It refers to the two ways that a closed system transfers energy to and from its surroundings - by the process of heating (or cooling) and the process of mechanical work.

This relates to effort & changes expended resulting in the creation of value and/or the creation of waste. We have activities that add value (which we hope is development), activities that preserve value (which is what much of SCM attempts do, given that it doesnt directly create the changes, but tries to ensure that changes happen and are built/integrated with minimal loss of energy/productivity/quality), and then we have activities (or portions of activities) that create waste (and increase entropy rather than preserving or increasing enthalpy/order)

Second Law of Thermodynamics
- In any isolated system that is not in equilibrium, entropy will increase over time
So this is the law of increasing instability/complexity/disorder. The "key" to preventing this from happening is achieving and then maintaining/preserving "equilibrium". How do we achieve such equlibrium? we do it with the "release enabler" patterns for codeline management (which help ensure "nested synchronization" and "harmonic cadence" in addition to achieving a balance or equilibrium between stability and velocity (to smooth out flow).

Third Law of Thermodynamics
- As temperature approaches absolute zero, the entropy of a system
approaches a constant minimum.
In our case, "Temperature" could be regarded as a measure of "energy" or "activity". As the energy/activity of a codeline approaches zero (such as a release in the field that youve been supporting and would LOVE to be able to retire that codeline sometime real soon), it's instability approaches a constant minimum.

This is perhaps another more polite way of saying something we already said in our article on "The Unchangeable Rules of Software Change", namely that "absolute stability" means dead (as in, "no activity"), and should serve as a reminder that our goals is not the prevention of change in order to achieve some ideal "absolute stability", for such an absolute would mean the project not just "done" but "dead".

On the other hand, it also speaks to us as a guideline for when it is safe to retire old codelines, and when to change their policy in accordance with their "energy level"
Posted by at No comments:
Labels: , ,

Monday, May 26, 2008

An Agile Approach to Release Management

My Agile SCM co-authors Rob Cowham, Steve Berczuk, and myself have written an article for the May CM Journal on An Agile Approach to Release Management

We're relatively pleased with the article, and all collaborated together quite well.
Posted by at 1 comment:
Labels: , ,

Tuesday, May 13, 2008

Distributed Version-Control Guide on InfoQ.com

Nice little guide on InfoQ.com about Distributed Version Control - that's twice in two months that the "agile" section of InfoQ.com has had a decent article on the subject!
Posted by at No comments:
Labels: ,

Monday, February 25, 2008

Distributed Version Control Systems

A colleague of mine had a question for me about Distributed Versions Control Systems (or DVCS). There are a growing number of such systems these days: Mercurial, Bazaar, git, svk, BitKeeper, Gnu Arch, darcs, Monotone, Codeville, Arx, just to name a few. I referred them to a good essay by David Wheeler that talks about the fundamental differences between distributed vs centralized VCS (among other things).

I also Googled on the topic and came across some interesting links:
Anyone else have any links they recommend on the topic? (please, no spam/marketing)
Posted by at 2 comments:
Labels: , ,

Monday, January 21, 2008

Best SCM Best Practices Article

The November 2007 issue of the CM Journal was devoted to the theme of "What Best Practice is Best?" Joe Farah's article on The Top 10 SCM Best Practices was quite possibly the best article on SCM best practices that I've come across to date!

Joe actually first lists his top ten "runners up" followed by his top ten. They are as follows (read the article if you see any terms that are unfamiliar to you):
    1. Use of Change Packages
    2. Stream-based Branching Strategy - do not overload branching
    3. Status flow for all records with Clear In Box Assignments
    4. Data record Owner and Assignee
    5. Continuous integration with automated nightly builds from the CM repository
    6. Dumb numbering
    7. Main branch per release vs Main Trunk
    8. Enforce change traceability to Features/Problem Reports
    9. Automate administration to remove human error
    10. Tailor your user interface closely to your process
    11. Org chart integrated with CM tool
    12. Change control of requirements
    13. Continuous Automation
    14. Warm-standby disaster recovery
    15. Use Live data CRB/CIB meetings
    16. A Problem is not a problem until it's in the CM repository
    17. Use tags and separate variant code into separate files
    18a. Separate Problems/Issues/Defects from Activities/Features/Tasks
    18b. Separate customer requests from Engineering problems/features
    19. Change promotion vs Promotion Branches
    20. Separate products for shared code
Granted, some of these may not be particularly Agile (nor were they meant to be specific to Agile development or Agile CM) but it's still a pretty darn good list in my opinion!
Posted by at 2 comments:
Labels: , ,

Thursday, January 17, 2008

Stellation Archives

Several years back there was an interesting open-source Eclipse project named "Stellation" at www.eclipse.org/stellation. It was to be an advanced/modern version control tool with lightweight branching and support for fine-grained checkout at the logical/semantic level.

Then about 2-3 years ago it just up and disappeared. I tried doing several websearches for it, but to no avail. Then on the revctrl mailing list I saw someone inquire about it, and I chimed in too wondering where it had gone.

Karl Fogel (of CVS and Subversion fame) replied with exactly what I was looking for ...

You can get the whole project archived as a tarball here:

http://archive.eclipse.org/technology/archives/stellation-project.tar.gz

It used to live at http://www.eclipse.org/stellation/. Those pages have been pulled, with no redirect left behind (a bit annoying when an open source project does that!).  But a search on eclipse.org pulled up this thread:

http://dev.eclipse.org/newslists/news.eclipse.foundation/msg00766.html

...which pointed to...

http://www.eclipse.org/technology/archived.php

...which pointed to the above tarball.  Summary from the archive page:
"Stellation is a software configuration management system designed to be an extensible platform for building systems based on the integration of advanced or experimental SCM techniques with the Eclipse development environment. The Stellation project will be using this system to integrate support for fine-grained software artifacts into the Eclipse environment, with particular focus on dynamic program organization, and inter-program coordination.

The Stellation website, newsgroup, mailing list, source code, and latest download are available in a compressed tar archive (110Mb) [http://archive.eclipse.org/technology/archives/stellation-project.tar.gz]"


So now you know! (and so do I).
Posted by at 1 comment:
Labels:

Tuesday, January 15, 2008

Understanding Version-Control

Eric Raymond, famed OpenSource co-founder and Unix guru, author of The Cathedral and the Bazaar and The Art of Unix Programming, is currently working on a draft of a work entitled "Understanding Version Control"

It is an interesting read, and covers some of the more recent systems like Bazaar and Mercurial. For those who wish to give feedback, there is a link you can follow for a reviewers' mailing list.
Posted by at No comments:
Labels:

Saturday, April 21, 2007

April CM Journal and LDM

The April issue of the CM Journal, and there is a FANTASTIC article in it by Austin Hastings about his Longacre Deployment Management strategy for dealing with database CM. It's long, but well worth the read for the insight into a new way of thinking about and doing CM of a database.

The April CM Basics issue has a companion/predecessor article a Case Study: Enterprise and Database CM the describes the initial problem, motivation and challenges that the LDM approach needed to solve. The LDM article goes into the gory technical details of the solution.
Posted by at 2 comments:
Labels: , ,

Sunday, April 01, 2007

Best Kept Secrets of Code Reviews

The folks over at SmartBear software have written a nice little book entitled The Best Kept Secrets of Code Reviews. It's free if you go over to their webpage and ask for it (you have to fill out a registration form, and it takes a few weeks to arrive, but they havent spammed me at all since I registered with them a few months ago).

This is a pretty good book and it is VERY pragmatic! It is applicable to Agile development too! [You don't have to do Pair-Programming to be Agile! Pairing is part of XP, which is one particular agile method -- several other agile methods do not require it.]

SmartBear also has a pretty neat suite of tools that look to me like they would be REALLY USEFUL for an organization trying to streamline some of its otherwise heavyweight processes for peer-reviews and related quality metrics:
  • CodeCollaborator - Automation for paperless peer code-reviews
  • CodeReports - Continuous source code metrics over time.
  • CodePickle - Suspend & resume code changes in local developer sandboxes (implements the PrivateVersions pattern without using version-control branches)
  • CodeReviewer - automated peer-to-peer code reviews across remote sites
  • CodeHistorian - Data-mining and visualizations for version control systems.

And "No!" they did not ask me to blog or say anything nice about them or their products! I'm simply coming from the perspective of someone in a large organization who has witnessed a lot of homegrown and heavyweight processes and tools for these kinds of things, and don't see too many commercial tools addressing the peer-review aspect of development and trying to make it lighter-weight and better-integrated with version-control and the rest of SCM.

The have some other nice resources too:

Looks like a lot of "good stuff" to me!!!
Posted by at 1 comment:
Labels: , , , ,

Wednesday, March 21, 2007

Lean-based Metrics for Agile CM Environments

My paper in this month's issue of The CM Journal is about Lean-based Metrics for Agile CM Environments.
    This month we take an "Agile" slant on metrics for CM, including the CM process itself. Agility is supposed to be people-centric and value-driven. So any metrics related to agility should, at least in theory, provide some indication of the performance & effectiveness of the value-delivery system, and how well it supports the people collaborating to produce that value. We borrow heavily from the concepts of Lean Production (and a little from the Theory of Constraints, a.k.a. TOC). Let's see where it takes us ....
Some readers will recognize some of the content from earlier blog-postings of mine on Codeline Flow, Availability and Throughput, Nested Synchronization and Harmonic Cadences and Feedback, Flow and Friction, but there is also a lot more content there too!
Posted by at No comments:
Labels: , , , ,

Saturday, December 30, 2006

Essential CVS and Global Outsourcing with VSTS

Just received two new books about version-control tools:
The Essential CVS, 2e book is one of the better CVS books available these days. I think I like it better than the classic one by Fogel, but not quite as much as the Pragmatic Programmers "Practical Version Control with CVS" (still - it's pretty close).

To be honest though, I really dont feel like CVS is very desirable among free Version-control tool offerings when we have the likes of Subversion, Monotone, Arch, and others that support the more recent paradigms and higher-levels of abstractions for working with project-wide streams (branches) and more.

The VSTS book is rather interesting. The "Global Outsourcing" parts of the title, and some of the corresponding content, would likely "turn off" a lot of folks. It even has a brief section about Agile development (to which, you'd think "global outsourcing would be anathema).

Mickey Gousset published a review of the book back in October, and it's worth a read. I mostly agree with the comments he makes. I think the book is pretty good, but there is another one coming soon that I expect I'll like a whole lot better, as well as several VSTS books available from Amazon.com.

Still, if you need to do a lot of distributed development across geographically dispersed sites, and want to use VSTS not just for its versioning capabilities, but also the tracking and coordination capabilities, this is probably the book to get.
Posted by at 1 comment:
Labels: , ,

Wednesday, December 20, 2006

Agile Tooling Survey Results

From Pete Behrens' Agile Executive Blog, the results to the Agile Tooling Survey they conducted in October are now available online at http://trailridgeconsulting.com/surveys.html:

    With over 500 survey responses from 39 countries, we feel this survey
    provides an excellent benchmark for where the agile movement is at
    today and how we are using project management tooling to assist our
    agile processes.

    This report builds a corporate profile of companies that are following
    agile processes today and then uses that profile to analyze how they
    are using project management tooling to support various aspects of
    their agile processes.

It's rather interesting to see what sorts of tools are being used for version-control, defect/issue/enhancement-tracking (DIET), and project planning & tracking, particularly when some high-profile Agilists would have us believe that (other than version control) Agile should "eschew" such tools.

I don't think the problem is the tools. I think the problem is most of them were/are made and used in a non-agile fashion that didn't have the agile way of working in mind. Now that there are some tools out there which do, it seems they are helpful after all :-)
Posted by at No comments:
Labels: , , , ,

Thursday, December 14, 2006

Product-Line CM in CACM

The current issue of Communications of the ACM is focused on Software Product-Lines for software engineering. It has a number of interesting articles on software product-lines and product-families for large-scale reuse.

It even has a few articles related to CM of product-lines, particularly change-management and variability-management:
Posted by at 2 comments:
Labels: , , ,

Friday, December 08, 2006

Dimensions and Views of SCM Architecture

The November issue of The Rational Edge has three articles that are closely related to my ideas about applying what we know about software & enterprise "architecture" to the domain of SCM/ALM solutions (and another article about an SCM tool vendor "eating their own dogfood"):


Some of you may recall my 4+2 Model Views of SCM Solution Architecture. I've since updated the picture a bit as follows (which Ive now updated over there too), click on the small image below to see a much larger one:



Anyway - reading through the above articles (particularly the one on model "dimensions" and the one on UML+RUP+Zachman together) gave me some more thoughts about my 4+2 views model, such as:

  • I have "scale & diversity" as a dimension of "concerns" that bridge all views. I wonder if that corresponds to the "scale" or "level" dimension referred to the in article on dimensions of system models?

  • I also have change/creation time, and decision binding time as a "dimension" of concerns. It's not explained real well though. I suppose it corresponds to considering both a "static" and "dynamic" perspective for each view. In a sense there are lifecycles (e.g., promotion cycles) for the elements in each view, as well as important times when decisions are committed to, and/or when artifacts or changes are made. When dealing with variation (diversity) across a product or system, the binding-time employed by the solution can be of great importance.

  • By adding a +2 view to RUP/Kruchten's original 4+1, I end up with something that sort of maps to the 6 columns of the Zachman model. Does this mean my 4+2views are really a subset of Enterprise Architecture (EA), or might it mean that its some kind of "bridge" between the two?

  • Does it really make sense for me to have Organization and data combined into a single view, or is Data really a separate view (a +3 view?), or should I not go so far as to equate metrics, queries and reports with "Data", but rather as the requirements for data (and hence the possible "bridge" mentioned above)?

  • What if I compare contrast my 4+2 views with the model or views put forth by any of ITIL, RUP-SE, DODAF, TOGAF, FEAF, or others (see below)? What value does mine add that warrants being its own "thing" instead of just some poor sawed-off wannabe clone of one of the others?

Anyways, these questiosn made me want to go look-up some of these other models and views. I found some pretty good online articles for some of them (I'm sure I missed a few as well). Here they are:


I welcome feedback/comments on any of my thoughts above!
Posted by at 2 comments:
Labels: , , , , ,

Monday, September 04, 2006

Relating SCM Patterns to SCM Principles

Our August Agile SCM column in the CM Journal is about Relating SCM Patterns to SCM Principles. The article is pretty flimsy, barely a skeleton, and that's pretty much entirely my my fault. I meant to write more "meat" about how certain principles are the underlying forces behind several patterns. I wanted to show how the principles are strongly related, much the same way patterns in a pattern language are related. And I wanted to show how that structure shaped the relationships between the patterns as well. Rob did a really good job trying to put together what I had with what he could come up with, but I didn't really give him enough and couldn't easily convey it in a way that made it easy for him to "run with it!"

It's not that I don't see those relationships, I do. And I'm not lacking for words to describe them either. I'm having trouble describing them clearly and concisely. A big part of that is because I still don't like the names of the SCM Principles as I've described them so far. Their names currently relate to the OOD Principles they were derived from. I think that might speak to programmers, but not to folks trying to do version control (even if they also wear "developer" hats). I really want to go back and rework the names of the principles to be more simple and direct.

This is something Ive been working in my mind on and off for alkmost a decade now. To me, it is of profound important - perhaps even the most significant contribution I'll have made to the field of SCM to date. THe interest level doesn't seem to be so high on the scm-patterns list and the cmcrossroads.com forums (but that hasn't deterred me - yet :). I really do think it's not a coincidence that principles of object-oriented design also manifest themselves as fundamental principles of SCM solution design (because I think both are all about architecture - and minimizing and managing dependencies).

I'd really like feedback. On this stuff so if you've had a chance to read thru the June, July and August Agile CM columns, I'm going to create a new YahooGroup about Agile-CM for discussing these and other Agile CM issues. Hopefully this new agile-cm group will have a healthy balance of both SCM folks and Agile development folks so we can have some constructive multi-faceted discussions.
Posted by at No comments:
Labels: , , , ,

Tuesday, August 29, 2006

More SCM Books in 2006

Some more SCM books have come on the market in the past 6 months or so. Several of them are worth a look: I realize Practical Perforce isn't new - I just can't stop gushing about how great it is! Laura Wingerd really has a gift for elegantly and simply stating important (and sometimes profound) insights about SCM, particularly when it comes to component/container-based SCM and codeline branching and management.

Global Outsourcing with VSTS looks interesting - not really sure if I like it enough to recommend it just yet. It certainly has an attention grabbing title.

The 2nd edition of Pragmatic Version Control using Subversion is just as outstanding as the first edition. It is my first choice for an introducitory book on Subversion and Version Control.

Kevin Lee's book on using ClearCase, ANT and CruiseControl is nothing short of outstanding. If you're a Java-shop using ClearCase and want lots of practical tips and tactics for doing automated builds and accelerating the build process, this book is a MUST HAVE! Kevin's website is also a great resource. Now that IBM/Rational has acquired BuildForge I imagine their will be updates at his website (and eventually a 2nd ed?) about using Clearcase with BuildForge (and maybe some stuff regarding Maven2?). He apparently has some new (online PDF-only) book out called The BuildMeister's Guide from a new series/publisher called Buildmeister books.

Pulsipher and Buckley did a great job in their earlier book The Art of ClearCase Deployment. Now they have a similar book about ClearQuest entititled Implementing IBM Rational ClearQuest: An End-to-End Deployment Guide. So far it looks very good. It's also the only ClearQuest book I know of - so If youre using ClearQuest for anything but a small or informal project you probably should get your hands on this book in a hurry!
Posted by at No comments:
Labels: , ,

Sunday, August 06, 2006

SCM as the Architecture of the Evolution of Architecture

One thing I particularly liked about my presentation of "SCM Patterns for Agile Architectures" at the Dr Dobbs Architecture & Design World 2006 conference in downtown Chicago...

I offered up several definitions or perspectives of SCM, including a traditional description, an Agile one, and an architectural one. I liked my architectural definition (I hadn't used that one before - I had used the other two in previous definitions). I said that, from an architectural perspective:

"Configuration Management is the Architecture of the Evolution of your Architecture!"


I rather liked that! I sort of used that to justify the title of the presentation, and presented an IEEE definition of architecture, along with Kruchten's 4+1 views model of software architecture. I then used that to justify my 4+2 model views of SCM/ALM solution architecture. I updated my drawing of the 4+2 model a bit. I think the addition of the Who+When+When+Where+Why+How shows how it may be a possible "bridge" between the Zachman Framework and the 4+1 views model.

Once again, the presentation is here. Feedback is welcome!
Posted by at No comments:
Labels: , , ,
Subscribe to: Posts (Atom)