1、 0-201-74117-2 Print 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
2、all software-related 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
3、tenets of the SPS. 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 become
4、s a part of the series 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 Met
5、skerThe Design Patterns 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
6、 Patterns Applied, 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 Busch
7、mannPattern Languages 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 co
8、deline and its componentsFigure 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. T
9、he SCM pattern languageFigure 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
10、 5-3. A Very Active 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
11、 many things.Figure 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 Assembl
12、es the Pieces.Figure 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
13、noise.Figure 17-1. 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 troubl
14、esome.Figure 19-3. 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 ar
15、chitecture seems lofty 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 archi
16、tecture usually have 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 soft
17、ware development process 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 desi
18、gning and building 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 p
19、articular J2EE construct, 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 t
20、he end of the day 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 disc
21、over in the last two 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
22、 can be seriously 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
23、patterns. As they 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.
24、 However, they more 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 ahea
25、d to the wonderful 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 impleme
26、nting processes, have 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
27、and IBM WebSphere 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 develo
28、pment is a key factor 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 se
29、veral years ago, and 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 soo
30、n begin to wield this 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 unde
31、rstanding organizations, 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
copyright@ 2008-2022 冰豆网网站版权所有
经营许可证编号:鄂ICP备2022015515号-1