SoftwareConfigurationManagementPatternsEffectiveTeamworkPracticalIntegration.docx

1、SoftwareConfigurationManagementPatternsEffectiveTeamworkPracticalIntegrationSoftware Configuration Management Patterns: Effective Teamwork, Practical Integration By Stephen P. Berczuk, Brad Appleton . Publisher: Addison Wesley Professional Pub Date: November 04, 2002 Print ISBN-10: 0-201-74117-2 Pri

2、nt ISBN-13: 978-0-201-74117-9 Pages: 256The Software Patterns SeriesSeries Editor: John M. VlissidesThe Software Patterns Series (SPS) comprises pattern literature of lasting significance to software developers. Software patterns document general solutions to recurring problems in all software-relat

3、ed spheres, from the technology itself, to the organizations that develop and distribute it, to the people who use it. Books in the series distill experience from one or more of these areas into a form that software professionals can apply immediately. Relevance and impact are the tenets of the SPS.

4、 Relevance means each book presents patterns that solve real problems. Patterns worthy of the name are intrinsically relevant; they are borne of practitioners experiences, not theory or speculation. Patterns have impact when they change how people work for the better. A book becomes a part of the se

5、ries not just because it embraces these tenets, but because it has demonstrated it fulfills them for its audience.Titles in the series:Design Patterns Explained: A New Perspective on Object-Oriented Design, Alan Shalloway/James R. TrottDesign Patterns Java Workbook, Steven John MetskerThe Design Pat

6、terns Smalltalk Companion, Sherman Alpert/Kyle Brown/Bobby WoolfThe Joy of Patterns: Using Patterns for Enterprise Development, Brandon GoldfedderThe Manager Pool: Patterns for Radical Leadership, Don Olson/Carol StimmelThe Pattern Almanac 2000, Linda RisingPattern Hatching: Design Patterns Applied,

7、 John VlissidesPattern Languages of Program Design, edited by James O. Coplien/Douglas C. SchmidtPattern Languages of Program Design 2, edited by John M. Vlissides/James O. Coplien/Norman L. KerthPattern Languages of Program Design 3, edited by Robert Martin/Dirk Riehle/Frank BuschmannPattern Langua

8、ges of Program Design 4, edited by Neil Harrison/Brian Foote/Hans RohnertSmall Memory Software, James Noble/Charles WeirSoftware Configuration Management Patterns, Stephen P. Berczuk/Brad AppletonFor more information, check out the series Web site at List of FiguresFigure I-1. A codeline and its com

9、ponentsFigure I-2. Populating a workspace from different codelinesFigure I-3. Branching a single file and merging with the trunkFigure I-4. Branching an entire codelineFigure I-5. Codeline diagram notationFigure 2-1. The interactions between elements of the environmentFigure 3-1. The SCM pattern lan

10、guageFigure 3-2. Codeline-related patternsFigure 3-3. Workspace-related patternsFigure 4-1. A merge can be messyFigure 4-2. Staircase branching (or a cascade)Figure 4-3. Mainline developmentFigure 5-1. Long-running tests have mixed value.Figure 5-2. A stable but dead codelineFigure 5-3. A Very Activ

11、e but very Useless CodelineFigure 5-4. An active, alive codelineFigure 5-5. Labeling Named Stable BasesFigure 6-1. Combining changes at onceFigure 6-2. Integrating each change as it happensFigure 6-3. Sharing Some Components between WorkspacesFigure 7-1. A workspace is created from many things.Figur

12、e 7-2 Populate your workspace from a repository.Figure 7-3. Version tree for a workspaceFigure 8-1. The build integrates changes from everyone.Figure 8-2. Components of the private system buildFigure 9-1. Integration can be difficult.Figure 9-2. An Integration Build Process Assembles the Pieces.Figu

13、re 10-1. Vendor releases and your releases are not in sync.Figure 10-2. Third party codelineFigure 12-1. Each codeline needs different rules.Figure 16-1. Each decision leads to more choices, until you pick the solution.Figure 16-2. Using the codeline for staging generates a lot of noise.Figure 17-1.

14、 Doing all your work on the mainlineFigure 17-2. Create a branch when you ship.Figure 17-3. Staircase of dependent branchesFigure 17-4. Release LineFigure 18-1. Release-Prep Code LineFigure 19-1. Some tasks are for the future.Figure 19-2. Creating a release line too early is troublesome.Figure 19-3.

15、 Task branchForewordThose of you familiar with my work may be asking yourselves why an expert on J2EE software architecture would be writing a preface for a book on software configuration management (SCM). After all, the two disciplines couldnt be farther apart, could they? J2EE architecture seems l

16、ofty and exalted, while SCM might appear to be something that is down in the muck of the trenches of software development. In fact, nothing could be further from the truth. Over the years, Ive often found that customers that I work with who have problems with J2EE application architecture usually ha

17、ve serious problems with SCM as well.The reasons for this curious coincidence are twofold. First, many people have a hard time dealing with change in generalbe it moving from a set of architectural practices that no longer apply in a new environment like J2EE, or moving from a software development p

18、rocess that worked in one environment but may not work in all environments as well. Thus they feel that if their SCM processes worked in their last project, they must work in their current projectregardless of the fact that the technologies, timescales, and methods employed in designing and building

19、 the two projects may be radically different.Second, people often want a small set of simple rules to govern all their activities. However, taking a too simple approach usually leads to problems at the edge where abstractions meet reality. Whether the issue is understanding why a particular J2EE con

20、struct, such as an Entity EJB, may work in one circumstance but not another, or understanding why it is important for developers to have their own private workspaces in which to do development and integration when, after all, you have to integrate the code from your developers at the end of the day

21、anyway, the problems are the same. In both cases, a simple rule (use Entity beans, use a build script) is perfectly good advice, but it must be tempered in the forge of experience because in its raw form it is too brittle to use.What mathematicians and scientists have begun to discover in the last t

22、wo decades of research into chaos and complexity theory is that, although systems built with rules that are too few and too simple are usually stagnant and predictable, adding just a few more rules can often lead to systems of startling complexity and beauty. These are systems that can be seriously

23、perturbed by outside forces and yet can reconstitute themselves so that the overall scheme remains whole. The book you hold in your hand provides a set of rules for SCM that have that kind of flexibility.Steve and Brad have developed their advice on dealing with SCM as a system of patterns. As they

24、tellingly reveal early on, the strength of a system of patterns lies not in the individual patterns themselves but in the web of relationships between the patterns. The authors have developed an interlocking mesh of patterns that individually cover the most common practices in SCM. However, they mor

25、e importantly show how the forces that lead to each solution are not completely resolved in each patternthat you need to carefully consider how each SCM practice is tied to others, to keep from locking yourself into a prison of your own making.For example, you may want to look ahead to the wonderful

26、 advice given in their first pattern, Mainline (4). This seemingly prosaic advice (that developers should work on a single, stable code base) is something that I have found many groups, including those in large, successful corporations that have spent millions of dollars on implementing processes, h

27、ave somehow failed to grasp. This is common sense, well applied, and that is what makes it uncommon.Likewise, the advice given in Private Workspace (6) and Private System Build (8) is nothing less than two of the key ideas that have made modern Java IDEs such as VisualAge for Java and IBM WebSphere

28、Studio so useful and popular. When I am asked (as I am nearly daily) why developers should choose one of these IDEs over development at the command line with traditional code editors and compilers, the fact that these tools not only allow but actively encourage this style of development is a key fac

29、tor in how I phrase my recommendations.So, I trust that you find this book as helpful and enlightening as I do. Ive been introducing people to a number of the patterns from this book since their first publication in the Pattern Languages of Programs (PLoP) Conference proceedings several years ago, a

30、nd Ive found them to be invaluable in setting the stage for frank and constructive discussions about how to perform SCM the right way. These patterns have been my sword for cutting through the Gordian knot of complex SCM issues in tricky customer engagementsI hope that you will soon begin to wield t

31、his weapon as well.KyleBrownAuthorofEnterprise Java Programming with IBM WebSpherePrefaceSoftware configuration management is not what I do. I am not a software configuration management person. I am not an organizational anthropology person. However, I discovered early on that understanding organiza

32、tions, software architecture, and configuration management was essential to doing my job as a software developer. I also find this systems perspective on software engineering interesting. I build software systems, and configuration management is a very important and often neglected part of building software systems. In this book, I hope that I can show you how to avoid some of the problems I have encountered so that yo