tag:blogger.com,1999:blog-10280668.post112063454918914144..comments2023-09-22T06:05:17.495-05:00Comments on Brad Appleton's ACME Blog: Whitgift's Principles of Effective SCMBrad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-10280668.post-1122378086642180472005-07-26T06:41:00.000-05:002005-07-26T06:41:00.000-05:00Hi Brad - thank you for keeping the conversation o...Hi Brad - thank you for keeping the conversation open here!<BR/><BR/><BR/>Re. OPEN / CLOSED, on projects so far I've had to provide some things that the tools seem to lack (rather than <EM>provide</EM> it's more like <EM>support</EM>, by our agreed working practices):<BR/><BR/>* preventing the alteration of tags that define a release, while...<BR/><BR/>* allowing free use of tags during development<BR/><BR/>(Maybe we haven't been using the best tools!)<BR/><BR/><BR/>Re. SUBSITUTION, I wonder if the analogy with OO principles is quite as strong? <BR/><BR/>Things like backward compatibility and package structure are, I feel, more to do with a product in itself - the 'stuff' whose configuration we are managing, as it slowly changes during development and successive releases.<BR/><BR/><BR/>MORE PRINCIPLES?<BR/><BR/>Maybe a database analogy could also suggest some 'candidate' principles... I just thought of third normal form, when expressed as 'the key, the whole key, and nothing but the key'. <BR/><BR/>This could suggest a principle of SCM usage like: "provide only what is <EM>both</EM> necessary and sufficient about a product configuration".<BR/><BR/>At a release, this would avoid ambiguity.<BR/><BR/>In development, one of the 'pains' that this could ease is the confusion and effort of dealing with 'cruft' - all faithfully tracked, of course.<BR/><BR/>I think I was reaching for something like this, earlier - when I was thinking in terms of <EM>features</EM>, like 'identifiable configurations' and 'explicit (complete?) access control'.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10280668.post-1122012328631934202005-07-22T01:05:00.000-05:002005-07-22T01:05:00.000-05:00Hi again Bob! EXCELLENT! You have arrived at exact...Hi again Bob! EXCELLENT! You have arrived at exactly the sort of tghing I'm seeking.<BR/><BR/>"OPEN for development, but CLOSED for release" sounds right on the monet to me! In the <A HREF="http://www.cmcrossroads.com/ubbthreads/showflat.php?Cat=0&Number=41248" REL="nofollow">"Principles of CM" thread on CMCrossroads.com</A> I translated the Open-Closed Principle into pretty much the same sentiment (great minds think alike :)<BR/><BR/>I called it the <I>Baseline Immutability Principle</I> or "BLIP" (meaning, once a configuration is "baselined", then the name/id of that baseline must always refer to the set of elements and versions it was made-up of at the time it was baselined.)<BR/><BR/>And I (perhaps loosely) translated the "Liskov Substitution Principle" into the <I>Configuration Promotion Principle</I>, and spoke of a possible <I>Codeline Consistency Principle</I> or <I>Codeline Integrity Principle</I>.Brad Appletonhttps://www.blogger.com/profile/15136106921504315995noreply@blogger.comtag:blogger.com,1999:blog-10280668.post-1121634972678720422005-07-17T16:16:00.000-05:002005-07-17T16:16:00.000-05:00Hi BradHow about:OPEN FOR DEVELOPMENT, CLOSED FOR ...Hi Brad<BR/><BR/>How about:<BR/><BR/>OPEN FOR DEVELOPMENT, CLOSED FOR RELEASE<BR/><BR/>OPEN means that any item can be...<BR/> * added to your SCM as a first version<BR/> * read for building and testing<BR/> * modified and superseded (ie the same item is added at a later version)<BR/> * tagged and re-tagged freely for tracking and co-ordination<BR/>...typically by software developers<BR/><BR/>CLOSED means that a combination of versions of items is identified, adjusted, confirmed...<BR/>...and that such a combination, once confirmed, defines a release<BR/><BR/>Perhaps that sounds simplistic? In my experience people do have to take special care to 'close' a release in their SCM system.<BR/><BR/>On my last team, we used a common 'product release' tag on all included items - each at the desired version. This tag was like 'Rx_y', as distinct from the tags like 'F123' that we used in the development of certain items for a given feature. <BR/><BR/>The tool did not support different meanings for the 'F' and 'R' tags; our conventions and discipline were needed to keep to the principle.<BR/><BR/>Now I can't think of another one!<BR/><BR/>regards<BR/>BobAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-10280668.post-1121583268648743622005-07-17T01:54:00.000-05:002005-07-17T01:54:00.000-05:00Interesting ideas Bob! Now I have to think harder ...Interesting ideas Bob! Now I have to think harder about what I consider a "principle." You have identified some objectives/abilities that you want as a result of "good" CM.<BR/><BR/>If those are things that CM "must" do (and not merely as a side-effect of achieving something else), than many would consider such "objectives" to be principles.<BR/><BR/>The kinds of principles I spoke of (when I compared them to Bob Martin's principles of OOD) are more like "invariants." They are conditions that must be be preserved or conserved in the design/implementation of a solution that meets such objectives.<BR/><BR/>If I dont preserve them ... if I violate them somehow, then something is out of balance, or perhaps more accurately, out of equilibrium. And either I didnt really achieve the objective I had set out to achieve, or I did so, but at the expense/neglect of something else or some other objective.<BR/><BR/>I guess that means I'm seeking principles as rules/invariants of SCM <I>design</I>.Brad Appletonhttps://www.blogger.com/profile/15136106921504315995noreply@blogger.comtag:blogger.com,1999:blog-10280668.post-1121531930577114472005-07-16T11:38:00.000-05:002005-07-16T11:38:00.000-05:00Hi Brad!I was thinking some more about the scope o...Hi Brad!<BR/><BR/>I was thinking some more about the <EM>scope</EM> of software configuration management... <BR/><BR/>Let's assume that it does not include: machine or network configuration; document management; or software deployment & distribution.<BR/><BR/>Let's assume that it does include: version control; build automation; and release management for 'stuff' (items, components, packages).<BR/><BR/>There are a few things that I either take for granted in SCM, or have wished were available. Maybe these things are more like principles:<BR/><BR/>COMPLETE HISTORY: all item versions are identifiable and retrievable (even if 'deleted' or 'moved')<BR/><BR/>IDENTIFIABLE CONFIGURATIONS: any combination of items, each at a particular version, can be identified in its own right (as well as, and independently of, individual revision numbers or tags on versions of items)<BR/><BR/>EXPLICIT ACCESS CONTROL: any configuration (say a 'release'), and any version of any item, can be made visible / readable / updatable (ie updatable for 'deletion' or 'movement', but not for replacement as that would violate COMPLETE HISTORY)<BR/><BR/>One might check how well these support the life cycle of creation, development, release, modification, support and retirement of 'stuff' by playing through some scenarios or use cases, I thought.<BR/><BR/>Thanks for thinking about this, and for opening up the whole discussion.<BR/><BR/>regards,<BR/>BobAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-10280668.post-1121373012916708042005-07-14T15:30:00.000-05:002005-07-14T15:30:00.000-05:00Hi Bob! Thanks for the comments. You identify some...Hi Bob! Thanks for the comments. You identify some good patterns (natural identification, apparent removal, etc.)<BR/><BR/>I say "patterns" rather than "principles" here because when I say principles I'm seeking more than guidelines or rules of thumb for what to do. Im looking for fundamental rules or "solution design principles" that should not be violated when doing a particular SCM practice or achieving an SCM objective. <BR/><BR/>For details see <A HREF="http://bradapp.blogspot.com/2005/04/principles-of-scm.html" REL="nofollow">my 20-April-2005 blog entry</A> or the <A HREF="http://www.cmcrossroads.com/ubbthreads/showflat.php?Cat=0&Number=41248" REL="nofollow">The Principles of CM</A> discussion thread on CMCrossroads.comBrad Appletonhttps://www.blogger.com/profile/15136106921504315995noreply@blogger.comtag:blogger.com,1999:blog-10280668.post-1120763358461083332005-07-07T14:09:00.000-05:002005-07-07T14:09:00.000-05:00If we take configuration management to be the disc...If we take configuration management to be the disciplined use of a tool or a service that supports the creation, development and maintenance of some system of interest; and if we take principles to be guidelines that can inform our practices; how about these for a start?<BR/><BR/>WHERE IS IT?<BR/><BR/>Natural identification: <BR/><BR/>Identify items by their real name (eg MyClass.java, my_package.sql). This avoids ambiguity when reading or updating items; it assumes that a naming convention applies when creating an item. <BR/><BR/>Apparent removal: <BR/><BR/>Remove an item from the scope of reading or updating; preserve the knowledge of its existence. This allows access to historical items, and avoids their accidental re-creation.<BR/><BR/>Unique location: <BR/><BR/>Find (and therefore put) an item in its natural place (eg java/com/ourcompany/package.jar, java/com/ourcompany/package/MyClass.java, oracle/my_schema/my_package.sql, java/org/junit/junit.jar). I think "use", not "reuse" (because the default way to reuse something is to, um, er, copy it).<BR/><BR/>And we probably need some more, perhaps under WHICH VERSION? <BR/><BR/>meaningful tags<BR/><BR/>minimise branches ("history is better than geography")<BR/><BR/>spot the difference<BR/><BR/>and ALL TOGETHER NOW!<BR/><BR/>locking or merging<BR/><BR/>etc...Anonymousnoreply@blogger.com