Source Code Management: Best Practices and Principles for Effective Software Development, Study notes of Software Engineering

Configuration Management Best Practices

Typology: Study notes

2017/2018

Uploaded on 03/04/2018

sean-senn
sean-senn 🇲🇾

1 document

1 / 268

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
ptg
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
pf34
pf35
pf36
pf37
pf38
pf39
pf3a
pf3b
pf3c
pf3d
pf3e
pf3f
pf40
pf41
pf42
pf43
pf44
pf45
pf46
pf47
pf48
pf49
pf4a
pf4b
pf4c
pf4d
pf4e
pf4f
pf50
pf51
pf52
pf53
pf54
pf55
pf56
pf57
pf58
pf59
pf5a
pf5b
pf5c
pf5d
pf5e
pf5f
pf60
pf61
pf62
pf63
pf64

Partial preview of the text

Download Source Code Management: Best Practices and Principles for Effective Software Development and more Study notes Software Engineering in PDF only on Docsity!

Praise for Configuration

Management Best Practices

“Understanding change is critical to any attempt to manage change. Bob Aiello and Leslie Sachs’s Confi guration Management Best Practices presents funda- mental definitions and explanations to help practitioners understand change and its potential impact.” —Mary Lou A. Hines Fritts, CIO and Vice Provost Academic Programs, University of Missouri-Kansas City

“Few books on software configuration management emphasize the role of people and organizational context in defining and executing an effective SCM process. Bob Aiello and Leslie Sachs’s book will give you the information you need not only to manage change effectively but also to manage the transition to a better SCM process.” —Steve Berczuk, Agile Software Developer, and author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration

“Bob Aiello and Leslie Sachs succeed handsomely in producing an important book, at a practical and balanced level of detail, for this topic that often ‘goes without saying’ (and hence gets many projects into deep trouble). Their passion for the topic shows as they cover a wonderful range of topics—even culture, personality, and dealing with resistance to change—in an accessible form that can be applied to any project. The software industry has needed a book like this for a long time!” —Jim Brosseau, Clarrus Consulting Group, and author of Software Teamwork: Taking Ownership for Success

“A must read for anyone developing or managing software or hardware projects. Bob Aiello and Leslie Sachs are able to bridge the language gap between the myr- iad of communities involved with successful Configuration Management imple- mentations. They describe practical, real world practices that can be implemented by developers, managers, standard makers, and even Classical CM Folk.” — Bob Ventimiglia, Bobev Consulting

Configuration

Management Best

Practices

This page intentionally left blank

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.

The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.

The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact:

U.S. Corporate and Government Sales (800) 382- [email protected]

For sales outside the United States please contact:

International Sales [email protected]

Visit us on the Web: informit.com/aw

Library of Congress Cataloging-in-Publication Data

Aiello, Bob, 1958- Configuration management best practices : practical methods that work in the real world / Bob Aiello, Leslie A. Sachs. p. cm. ISBN 978-0-321-68586-5 (pbk. : alk. paper) 1. Information technology--Management. 2. Configuration management. I. Sachs, Leslie A., 1961- II. Title. T58.64.A35 2010 004.068’5--dc 2010022175

ISBN-13: 978-0-321-68586- ISBN-10: 0-321-68586-

Copyright © 2011 Pearson Education, Inc.

All rights reserved. Printed in the United States of America. This publication is protected by copy- right, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to:

Pearson Education, Inc. Rights and Contracts Department 501 Boylston Street, Suite 900 Boston, MA 02116 Fax (617) 671-

Text printed in the United States on recycled paper at R.R. Donnelley in Crawfordsville, Indiana.

First printing August 2010

Editor-in-Chief Karen Gettman Acquisitions Editor Chris Guzikowski Senior Development Editor Chris Zahn Managing Editor Kristy Hart Project Editor Jovana San Nicolas- Shirley Copy Editor Keith Cline Indexer Erika Millen Proofreader Sheri Cain Cover Designer Gary Adair Compositor Gloria Schurick

Dedicated to Benjamin K. Sachs

Those who met Ben did not easily forget the soft-spoken, yet

articulate engineer with the deep blue eyes and gracious manner.

Respected by family, friends, and business associates alike, he

was known for his remarkable intelligence, integrity, and pas-

sion for excellence. Ben is also remembered fondly by the many

people whose lives he touched with his warmth, kindness, and

generosity. His successful career provided ample evidence to sup-

port the firm belief that “doing the right thing” will inevitably

result in better quality, higher productivity, increased shareholder

value, and more satisfied, loyal customers. Ever the promoter

of good corporate citizenship, Ben combined his high morals

and ethical standards with a natural optimism to create win-win

resolutions for even the most challenging situations. Both our

personal and professional development have been tremendously

enhanced as a result of his wisdom and loving guidance.

Thank you, Dad, for never passing up the opportunity to

enthusiastically express both your confidence in our abilities

and pride in our accomplishments and for so eagerly sharing

your infectious joy in living!

Bob Aiello and Leslie Sachs

Contents

Preface xxi

9.5.4 An Extremely Brief Description That I Hope

  • PART I THE CORE CM BEST PRACTICES FRAMEWORK ................... Introduction xxxiii
  • Chapter 1 Source Code Management .......................................................... - Terminology and Source Code Management
    • Goals of Source Code Management
    • Principles of Source Code Management
    • 1.1 Why Is Source Code Management Important?
    • 1.2 Where Do I Start?
    • 1.3 Source Code Management Core Concepts - 1.3.1 Creating Baselines and Time Machines - 1.3.2 Reserved Versus Unreserved Checkouts - 1.3.3 Sandboxes and Workspaces - 1.3.4 Variant Management (Branching) - 1.3.5 Copybranches Versus Deltas - 1.3.6 How to Handle Bugfixes - 1.3.7 Streams - 1.3.8 Merging - 1.3.9 Changesets
    • 1.4 Defect and Requirements Tracking
    • 1.5 Managing the Globally Distributed Development Team
    • 1.6 Tools Selection - 1.6.1 Open Source Versus Commercial - 1.6.2 Product Maturity and Vendor Commitment - 1.6.3 Extensibility and Open API - Management 1.6.4 Don’t Overengineer Your Source Code
      • Ownership) 1.7 Recognizing the Cost of Quality (and Total Cost of
        • 1.7.1 Building Your Source Code Management Budget
    • 1.8 Training x Contents
      • 1.8.1 The “Bob Method” for Training
    • 1.9 Defining the Usage Model
    • 1.10 Time to Implement and Risks to Success
    • 1.11 Establishing Your Support Process
    • 1.12 Advanced Features and Empowering Users
    • Conclusion
  • Chapter 2 Build Engineering
    • Goals of Build Engineering
    • Principles of Build Engineering
    • 2.1 Why Is Build Engineering Important?
    • 2.2 Where Do I Start?
    • 2.3 Build Engineering Core Concepts
      • 2.3.1 Version IDs or Branding Your Executables
      • 2.3.2 Immutable Version IDs
      • 2.3.3 Stamping In a Version Label or Tag
      • 2.3.4 Managing Compile Dependencies
      • 2.3.5 The Independent Build
    • 2.4 Core Considerations for Scaling the Build Function
      • 2.4.1 Selling the Independent Build
      • 2.4.2 Overengineering the Build
      • 2.4.3 Testing Your Own Integrity
        • of Interest 2.4.4 Reporting to Development Can Be a Conflict
      • 2.4.5 Organizational Choices
    • 2.5 Build Tools Evaluation and Selection
      • 2.5.1 Apache Ant Enters the Build Scene
      • 2.5.2 Of Mavens and Other Experts
      • 2.5.3 Maven Versus Ant
      • 2.5.4 Using Ant for Complex Builds
      • 2.5.5 Continuous Integration
      • 2.5.6 CI Servers
      • 2.5.7 Integrated Development Environments
      • 2.5.8 Static Code Analysis
      • 2.5.9 Build Frameworks
      • 2.5.10 Selecting Your Build Tools Contents xi
      • 2.5.11 Conducting the Bakeoff and Reaching Consensus
    • 2.6 Cost of Quality and Training
    • 2.7 Making a Good Build Better
      • 2.7.1 “Bob-Proofing” Your Build
      • 2.7.2 Test-Driven Builds
      • 2.7.3 Trust, But Verify
      • 2.7.4 The Cockpit of a Plane
    • 2.8 The Role of the Build Engineer
      • 2.8.1 Know What You Build
      • 2.8.2 Partner with Developers
      • 2.8.3 Drafting a Rookie
    • 2.9 Architecture Is Fundamental
    • 2.10 Establishing a Build Process
      • 2.10.1 Establishing Organizational Standards
    • 2.11 Continuous Integration Versus the Nightly Build
    • 2.12 The Future of Build Engineering
    • Conclusion
  • Chapter 3 Environment Configuration
    • Goals of Environment Configuration Control
    • Principles of Environment Configuration Control
    • 3.1 Why Is Environment Configuration Important?
    • 3.2 Where Do I Start?
    • 3.3 Supporting Code Promotion
    • 3.4 Managing the Configuration
      • 3.4.1 Which Database Are You Using?
      • 3.4.2 Did That Trade Go Through?
      • 3.4.3 How About a Few Tokens?
      • 3.4.4 Centralizing the Environment Variable Assignment
    • 3.5 Practical Approaches to Establishing a CMDB
      • 3.5.1 Identify and Then Control
      • 3.5.2 Understanding the Environment Configuration
    • 3.6 Change Control Depends on Environment Configuration
    • 3.7 Minimize the Number of Controls Required
    • 3.8 Managing Environments
    • 3.9 The Future of Environment Configuration xii Contents
    • Conclusion
  • Chapter 4 Change Control
    • Goals of Change Control
    • Principles of Change Control
    • 4.1 Why Is Change Control Important?
    • 4.2 Where Do I Start?
    • 4.3 The Seven Types of Change Control
      • 4.3.1 A Priori
      • 4.3.2 Gatekeeping
      • 4.3.3 Configuration Control
      • 4.3.4 Change Advisory Board
      • 4.3.5 Emergency Change Control
      • 4.3.6 Process Engineering
      • 4.3.7 Senior Management Oversight
    • 4.4 Creating a Change Control Function
    • 4.5 Examples of Change Control in Action
      • 4.5.1 The 29-Minute Change Control Meeting
      • 4.5.2 Change Control at the Investment Bank
      • 4.5.3 Change Control at the Trading Firm
      • 4.5.4 Forging Approvals
    • 4.6 Don’t Forget the Risk
    • 4.7 Driving the CM Process Through Change Control
    • 4.8 Entry/Exit Criteria
    • 4.9 After-Action Review
    • 4.10 Make Sure That You Evaluate Yourself
    • Conclusion
  • Chapter 5 Release Management
    • Goals of Release Management
    • Principles of Release Management
    • 5.1 Why Is Release Management Important?
    • 5.2 Where Do I Start?
    • 5.3 Release Management Concepts and Practices
      • 5.3.1 Packaging Strategies That Work
      • 5.3.2 Package Version Identification
      • 5.3.3 Sending a Release Map with the Release Contents xiii
      • 5.3.4 What Does Immutable Mean?
    • 5.4 The Ergonomics of Release Management
      • 5.4.1 Avoiding Human Error
      • 5.4.2 Understanding the Technology
      • 5.4.3 Tools from Build Engineering
      • 5.4.4 Avoiding Human Error
      • 5.4.5 My Own Three-Step Process
      • 5.4.6 Too Many Moving Parts
    • 5.5 Release Management as Coordination
      • 5.5.1 Communicating the Status of a Release
      • 5.5.2 Don’t Forget the Release Calendar
      • 5.5.3 RM and Configuration Control
    • 5.6 Requirements Tracking
    • 5.7 Taking Release Management to the Next Level
      • 5.7.1 Using Cryptography to Sign Your Code
      • 5.7.2 Operating Systems Support for Release Management
      • 5.7.3 Improving Your RM Process
    • Conclusion
  • Chapter 6 Deployment
    • Goals of Deployment
    • Principles of Deployment
    • 6.1 Why Is Deployment Important?
    • 6.2 Where Do I Start?
    • 6.3 Practices and Examples
      • 6.3.1 Staging Is Key
      • 6.3.2 Scripting the Release Process Itself
      • 6.3.3 Frameworks for Deployment
      • 6.3.4 What If Bob Makes a Mistake?
      • 6.3.5 More on the Depot
      • 6.3.6 Auditing Your Release
    • 6.4 Conducting a Configuration Audit
    • 6.5 Don’t Forget the Smoke Test
    • 6.6 Little Things Matter a Lot
    • 6.7 Communications Planning
      • 6.7.1 Announcing Outages and Completed Deployments
    • 6.8 Deployment Should Be Delegated xiv Contents
    • 6.9 Trust But Verify
    • 6.10 Improving the Deployment Process
    • Conclusion
  • PART II ARCHITECTURE AND HARDWARE CM
  • Chapter 7 Architecting Your Application for CM
    • Goals of Architecting Your Application for CM
    • 7.1 Why Is Architecture Important?
    • 7.2 Where Do I Start?
    • 7.3 How CM Facilitates Good Architecture
    • 7.4 What Architects Can Learn From Testers
      • 7.4.1 Testing as a Service to the Developers
    • 7.5 Configuration Management–Driven Development (CMDD)
    • 7.6 Coping with the Changing Architecture
    • 7.7 Using Source Code Management to Facilitate Architecture
    • 7.8 Training Is Essential
    • 7.9 Source Code Management as a Service
    • 7.10 Build Engineering as a Service
    • Conclusion
  • Chapter 8 Hardware Configuration Management
    • Goals of Hardware CM
    • 8.1 Why Is Hardware CM Important?
    • 8.2 Where Do I Start?
    • 8.3 When You Can’t Version Control a Circuit Chip
      • 8.3.1 A Configuration Item by Any Other Name
      • 8.3.2 Version Control for Design Specifications
    • 8.4 Don’t Forget the Interfaces
    • 8.5 Understanding Dependencies
    • 8.6 Traceability
    • 8.7 Deploying Changes to the Firmware
    • 8.8 The Future of Hardware CM
    • Conclusion
  • PART III THE PEOPLE SIDE OF CM Contents xv
  • Chapter 9 Rightsizing Your Processes
    • Goals of Rightsizing Your CM Processes
    • 9.1 Why Is Rightsizing Your Processes Important?
    • 9.2 Where Do I Start?
    • 9.3 Verbose Processes Just Get in the Way
    • 9.4 SPINs and Promoting the CMM
    • 9.5 Disappearing Verbose Processes
      • 9.5.1 Agile Processes Just Work
      • 9.5.2 Open Unified Process
      • 9.5.3 Getting Lean
        • Software Development Motivates You to Take a Closer Look at Lean
    • 9.6 The Danger of Having Too Little Process
    • 9.7 Just-in-Time Process Improvement
    • 9.8 Don’t Overengineer Your CM
    • 9.9 Don’t Forget the Technology
    • 9.10 Testing Your Own Processes
    • 9.11 Process Consultation
      • 9.11.1 Transparency That Is Genuine
    • 9.12 Create a Structure for Sustainability
    • Conclusion
  • Chapter 10 Overcoming Resistance to Change.
    • Goals of Overcoming Resistance to Change
    • 10.1 Why Is Overcoming Resistance to Change Important?
    • 10.2 Where Do I Start?
    • 10.3 Matching Process to Culture
    • 10.4 Mixing Psychology and Computer Programming
    • 10.5 Process Improvement from Within
    • 10.6 Picking Your Battles
    • 10.7 Fostering Teamwork
    • 10.8 Why Good Developers Oppose Process Improvement
    • 10.9 Procedural Justice
  • 10.10 Input from Everyone xvi Contents
  • 10.11 Showing Leadership
  • 10.12 Process Improvement People May Be the Problem
  • 10.13 Combining Process and Technology Training
  • 10.14 Listening to the Rhythm
  • 10.15 Processes Need to Be Tested
  • 10.16 Baby Steps and Process Improvement
  • 10.17 Selling Process Improvement
  • 10.18 What’s in It for Me?
  • 10.19 Process Improvement as a Service
  • 10.20 Guerrilla Tactics for Process Improvement
  • Conclusion
    • the Workplace Chapter 11 Personality and CM: A Psychologist Looks at
  • Goals of Understanding Personality: What’s in It for Me?
  • 11.1 Personality Primer for CM Professionals - Terms of Personality? 11.2 What Do CM Experts Need to Consider in - 11.2.1 Communication Styles - Language Differently? 11.2.2 Do Men and Women Use and Interpret - 11.2.3 Effective Consultation - 11.2.4 Verifying the Message - 11.2.5 Information Processing Preferences - 11.2.6 Birth Order at Work - 11.2.7 Firstborns as Leaders - 11.2.8 The Middle-Born Compromiser - 11.2.9 The Youngest as Initiator - 11.2.10 The Only Child - 11.2.11 Being Yourself
  • 11.3 Applying Psychology to the Workplace - 11.3.1 Effective Teamwork Begins at Home - 11.3.2 Volleyball or Effective Collaboration - the Development Team 11.3.3 Embedding Build Engineers and Testers in - 11.3.4 Blackbox Versus Whitebox Versus Graybox - Organization 11.3.5 Group Dynamics That Can Damage the - 11.3.6 Where CM and QA Fit In
    • 11.4 Family Dynamics!
      • 11.4.1 Indecisiveness
    • 11.5 Workplace Culture and Personality
      • 11.5.1 Personality and Structure
      • 11.5.2 We Already Invented All the Good Ideas
      • 11.5.3 Loose Cannons Who Don’t Want to Comply
        • Train Moving 11.5.4 Enforcing Process, While Still Keeping the
      • 11.5.5 Formulas for Success
      • 11.5.6 Caveats
    • Conclusion
  • Chapter 12 Learning From Mistakes That I Have Made
    • Goals of Learning from Mistakes
    • 12.1 Why Is It Important to Learn from Our Mistakes?
    • 12.2 Where Do I Get Started?
    • 12.3 Understanding Our Mistakes
    • 12.4 The Mistakes I Have Made
      • 12.4.1 Missing the Big Picture
      • 12.4.2 Writing Release Automation Can Be Challenging
      • 12.4.3 Thinking That a Good Process Will Carry Itself
      • 12.4.4 Failing to Gain Consensus
      • 12.4.5 Failing to Show Leadership for CM
      • 12.4.6 Becoming Part of the Problem
      • 12.4.7 Forgetting to Ask for Help
    • 12.5 Turning a Mistake into a Lesson Learned
      • 12.5.1 Clarifying What I Need to Get the Job Done
      • 12.5.2 Getting the Training That I Need
    • 12.6 Common Mistakes That I Have Seen Others Make
      • 12.6.1 Ivory Tower
      • 12.6.2 Failing to Get Technical and Hands-On
      • 12.6.3 Not Being Honest and Open
    • Conclusion
  • PART IV COMPLIANCE, STANDARDS, AND FRAMEWORKS xviii Contents
  • Chapter 13 Establishing IT Controls and Compliance
    • Goals of Establishing IT Controls and Compliance
    • 13.1 Why Are IT Controls and Compliance Important?
    • 13.2 How Do I Get Started?
    • 13.3 Understanding IT Controls and Compliance
      • 13.3.1 Sarbanes-Oxley Act of
      • 13.3.2 Management Assessment of Internal Controls
      • 13.3.3 Committee of Sponsoring Organizations
      • 13.3.4 Cobit as a Framework for IT Controls
        • on the Assessment Made by the Management? 13.3.5 What Does It Mean to Attest to And Report
        • Act of 13.3.6 Health Insurance Portability and Accountability
      • 13.3.7 When the GAO Comes Knocking
      • 13.3.8 Results of the Audit
        • Management Practices 13.3.9 GAO Reports on NARA’s Configuration
      • 13.3.10 ERA Configuration Management Plan
      • 13.3.11 Areas for Improvement
      • 13.3.12 Understanding the Results of the Audit
      • 13.3.13 Office of the Comptroller of the Currency
    • 13.4 Essential Compliance Requirements - Releases 13.4.1 Providing Traceability of Requirements to
      • 13.4.2 Production Separation of Controls
    • 13.5 The Moral Argument for Supporting CM Best Practices
    • 13.6 Improving Quality and Productivity Through Compliance
    • 13.7 Conducting a CM Assessment
      • 13.7.1 Assessment First Steps
        • Situation Appears 13.7.2 Listen First Regardless of How Bad the
    • Conclusion
  • Chapter 14 Industry Standards and Frameworks
    • Goals of Using Industry Standards and Frameworks
    • 14.1 Why Are Standards and Frameworks Important?
    • 14.2 How Do I Get Started? Contents xix
    • 14.3 Terminology Required
      • 14.3.1 Configuration Item
      • 14.3.2 Configuration Identification
      • 14.3.3 Configuration Control
      • 14.3.4 Interface Control
      • 14.3.5 Configuration Status Accounting
      • 14.3.6 Configuration Audit
      • 14.3.7 Subcontractor/Vendor Control
      • 14.3.8 Conformance Versus Noncompliance
    • 14.4 Applying These Terms to the Standards and Frameworks
    • 14.5 Industry Standards - Management Plans 14.5.1 IEEE 828—Standard for Software Configuration - Guidelines for Configuration Management 14.5.2 ISO 10007—Quality Management Systems— - Standard for Configuration Management 14.5.3 ANSI/ITAA EIA-649-A—National Consensus
      • 14.5.4 ISO/IEC/IEEE 12207 and
    • 14.6 Industry Frameworks
      • 14.6.1 ISACA Cobit
      • 14.6.2 CMM/CMMI
      • 14.6.3 itSMF’s ITIL Framework
      • 14.6.4 SWEBOK
      • 14.6.5 Open Unified Process (OpenUP)
      • 14.6.6 Agile/SCRUM
    • Conclusion
  • Index