39,59 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Why is Software Configuration Management important?Software Configuration Management (SCM) is the discipline of managing the building and modification of software through techniques including source-code control, revision control, object-build tracking, and release construction. SCM involves identifying the configuration of the software at given points in time, systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the software development lifecycle.Software Configuration Management is one of the first skills a serious developer should master, after becoming proficient with his or her development tools of choice. Unfortunately, this does not always happen because the subject of SCM is not commonly taught in either academic or company training.When developing software, you need to have a manageable team development effort, track and maintain the history of your projects, sustain parallel development on multiple product versions, fix bugs, and release service packs while further developing the application. This is where the concepts of Software Configuration Management come into play; SCM is about getting the job done safer, faster, and better.Visual SourceSafe has a long history behind it. The previous versions were either loved for their ease of use and integration with other Microsoft products, or hated because the headaches caused by using them improperly. This book will help you to avoid such problems.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 327
Veröffentlichungsjahr: 2007
Ähnliche
Table of Contents
Visual SourceSafe 2005 Software Configuration Management in Practice
Alexandru Serban
Visual SourceSafe 2005 Software Configuration Management in Practice
Copyright © 2007 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, Packt Publishing, nor its dealers or distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: February 2007
Production Reference: 1090207
Published by Packt Publishing Ltd. 32 Lincoln Road Olton Birmingham, B27 6PA, UK.
ISBN 978-1-904811-69-5
www.packtpub.com
Cover Image by www.visionwt.com
Credits
Author
Alexandru Serban
Reviewers
Alin Constantin
Dragos Brezoi
Jean-Baptiste Lab
Development Editor
Cristian Darie
Technical Editor
Saurabh Singh
Editorial Manager
Dipali Chittar
Project Manager
Patricia Weir
Project Coordinator
Abhijeet Deobhakta
Indexer
Bhushan Pangaonkar
Proofreader
Chris Smith
Layouts and Illustrations
Shantanu Zagade
Cover Designer
Shantanu Zagade
About the Author
Alexandru Serban is the founder and CEO of Unievo, a new software development company.
Previously, he worked as a .NET Software Architect with Softwin and Microsoft on extending Visual Studio for enterprise infrastructure projects. In 2004, he co-authored Pro .NET 1.1 Network Programming, Second Edition.
Alexandru has been driven by the computer revolution ever since he can remember. Now he plans to be a part of it.
When not planning to take over the word, he likes to drive and travel, in the summer to the sea and in the winter to the mountains, where he hits the slopes with his snowboard.
About the Reviewers
Alin Constantin graduated from the Faculty of Automatic Control and Computers of the Politehnica University of Bucharest in 1997. He worked at Crinsoft S.R.L., developing hotel management and user interface automation software. Then in 1999 he joined Microsoft. For almost 7 years he focused on developing Visual SourceSafe and source control integration in Visual Studio.
Dragos Brezoi started programming to create an application for processing and adding extra effects to his guitar's sound. Several years later, he got a Masters Degree in Computer Science from the Politehnica University of Bucharest, and is now researching for a Ph.D. in Advanced Automatics. Dragos worked for several years in the industrial automation field as a programmer for PLC and DSP programming to SCADA, OPC, and DCS solutions. Dragos co-authored GDI+ Custom Controls with Visual C# 2005 (Packt Publishing, 2006), and he currently works for Motorola TTPCom Product Group (Denmark), developing a next-generation embedded software framework.
Jean-Baptiste Lab discovered computers at the age of 12, when he started writing demos in assembly to impress his friends. After a scientific-oriented basic education, he obtained a B.Sc. in Computer Science at Portsmouth University, UK in 1998, and went on to achieve an M.Sc. in Mathematics and Computing at the University of Besancon, France. Expatriated in Denmark, Jean-Baptiste has been working in the mobile phone industry since 2001, touching various fields spanning from GSM Protocol Stack simulation to software architecture, build systems, and configuration management.
Preface
Software Configuration Management (SCM) is one of the first skills a serious developer should master, after becoming proficient with his or her development tools of choice. Unfortunately this doesn't always happen because the subject of SCM is not commonly taught in academic or company training.
Although software is not a material thing, as you cannot touch it, smell it, or taste it, building software can be as complex as building physical things such as cars or planes, if not more so. The main difference between the two worlds lies in the limitations you confront. In the world of developing software there are no physical limitations—the only limit is your imagination.
However, all this freedom can have a downside. A good TV commercial once stated "Power is nothing without control"—if you do not control it wisely, it may start working against you. When developing software, you need to have a manageable team development effort, track and maintain the history of your projects, sustain parallel development on multiple product versions, fix bugs, and release service packs while further developing the applications.
This is where the concept of Software Configuration Management (SCM) comes into play, dealing among other things with source code versioning, tracking development evolution, building, and releasing. Putting it in simple terms, SCM is about getting the job done safer, faster, and better.
While trying to keep the theory to a minimum, this book starts by teaching you what SCM is, why it is important, and what benefits you get by using it, either by working individually or by being part of a team. You will find this part very valuable if you're new to the concept of SCM, because you will be setting your base for understanding what happens in the rest of the book.
Then the book concentrates on the Microsoft Visual SourceSafe 2005 SCM tool and the best practices used to manage the development and evolution of Visual Studio .NET 2005 applications. You will learn the theory by going through a journey, in which we will actually develop a new application, starting from designing its specifications and ending with releasing it and completing the Software Development Lifecycle (SDLC).
You will learn how the SCM concepts are applied by Visual SourceSafe 2005 by developing Orbital Hotel, a Service-Oriented Application hotel reservation system. You will learn how to use the team cooperation features in Visual SourceSafe 2005 with the help of John and Mary, two fictional team members who have been assigned to implement various project components.
The end of the book deals with SourceSafe administration tasks. It describes SourceSafe database creation, management, and maintenance, how to secure the database, how to create users and assign user rights, and how to manage projects and project settings.
Additional material on how to customize SourceSafe to suit your development style is available at http://www.packtpub.com/visual-sourcesafe-2005/book. You can visit Orbital Hotel online at http://orbitalhotel.alexandruserban.com/.
I hope you will find this book a great resource about Visual SourceSafe 2005, and I hope you will enjoy reading it as much as I enjoyed writing it!
What This Book Covers
Chapter 1 teaches you the basic terminology and concepts used in the SCM world, and how SCM integrates in the Software Development Lifecycle.
Chapter 2 introduces you to Microsoft's SCM tool for small and medium teams: Visual SourceSafe 2005. You'll learn what this product is made of, and what new features and improvements it has over the previous versions.
Chapter 3 introduces Orbital Hotel, a hotel-reservation system application, which will be used in the next chapters as a case study for developing Visual Studio applications with SourceSafe. We will see what the best structure for Visual Studio solutions is when working under Source Control.
Chapter 4 discusses the various ways you can add a software project to the SourceSafe database. This is the first step you'll take when starting to develop an application under Source Control.
Chapter 5 covers the Source Control operations used daily in our development activities. We'll set up a new workspace and get the solution from the SourceSafe database. Then, we will add new files to the solution, check them in, examine their history, and get latest versions. We will also explore the team-cooperation models and see what are the differences between them, their advantages and disadvantages, and operations such as item comparison, undoing changes, file merging and pinning, and conflict resolution.
Chapter 6 teaches you how to access the SourceSafe server through the intranet or the Internet, in order to perform the necessary Source Control tasks. If you don't have an internet connection at the remote location, or if the local SourceSafe server is temporarily down, you can work offline, provided you already have the solution files on your remote machine. When a connection to the database becomes available again, you reconnect to the SourceSafe database and synchronize the changes. Depending on the database configuration and the Visual Studio plug-ins you use while reconnecting, there are some scenarios to consider for avoiding data loss. We will examine the possible scenarios that can lead to data loss and see how to avoid such situations.
Chapter 7 teaches you how to manage the software development lifecycle using SourceSafe. In the evolution of software products there are many milestones. We will see how to manage them using SourceSafe so that we can reproduce their specific configurations when needed. We will also talk about the build process and how a periodical build can catch integration problems early on. We will take a brief look at white-box and black-box tests and how they help in ensuring final product quality. Last but not the least, we will see how to maintain multiple product versions to be able to release service packs while continuing development towards the next versions.
Appendix A covers the installation steps for Visual SourceSafe 2005 and the configuration for remote access.
Appendix B describes how to perform SourceSafe database administration tasks such as creating and securing databases, managing database and Windows users, creating shadow folders, and configuring the services for the SourceSafe plug-ins in Visual Studio.
Appendix C discusses how to perform maintenance tasks on SourceSafe databases such as undoing user checkouts, changing the team version control model, locking, archiving, restoring, and running database maintenance tools.
Note
Additional material on Customizing Visual SourceSafe 2005 is available at http://www.packtpub.com/sourcesafe/book.
What You Need for This Book
To follow this book you need Visual SourceSafe 2005, and Visual Studio .NET 2005 Standard edition or above.
Who This Book is For
This book is for .NET developers, testers, and configuration managers who:
The book doesn't assume previous experience with any software configuration tool and is a great resource for people who want to start learning about this subject.
Conventions
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
There are three styles for code. Code words in text are shown as follows: "In the third page we have to specify the LAN network path to the database shared folder that contains the srcsafe.ini file."
A block of code will be set as follows:
Any command-line input and output is written as follows:
New terms and important words are introduced in a bold-type font. Words that you see on the screen, in menus or dialog boxes for example, appear in our text like this: "The path can be entered manually or by using the Browse button to browse the network for the specific path."
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader Feedback
Feedback from our readers is always welcome. Let us know what you think about this book, what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply drop an email to <[email protected]>, making sure to mention the book title in the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Customer Support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the Example Code for the Book
Visit http://www.packtpub.com/support, and select this book from the list of titles to download any example code or extra resources for this book. The files available for download will then be displayed.
The downloadable files contain instructions on how to use them.
Errata
Although we have taken every care to ensure the accuracy of our contents, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in text or code—we would be grateful if you would report this to us. By doing this you can save other readers from frustration, and help to improve subsequent versions of this book. If you find any errata, report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the Submit Errata link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata are added to the list of existing errata. The existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Questions
You can contact us at <[email protected]> if you are having a problem with some aspect of the book, and we will do our best to address it.
Chapter 1. Controlling the Evolution of Software Products
On April 30, 1999, a Titan IV B rocket carrying a military satellite into orbit was launched from Space Launch Complex 40 at Cape Canaveral Air Station, Florida. The flight performance of the Titan solid rocket motor and the core vehicle was nominal. However, the vehicle began experiencing instability about the roll axis during the first burn. This instability was greatly magnified during the upper stage second main engine burn, resulting in uncontrolled vehicle tumbling. As a result of these anomalous events the satellite was placed in an unusable low elliptical final orbit instead of an intended geosynchronous orbit. After several days of satellite life-saving effort by Air Force and satellite contractor personnel the satellite was declared a complete loss by the acting secretary of the Air Force on 4 May 1999.
The investigation into this accident concluded that the cause was due to a failed software development, testing, and quality assurance process. This process did not detect and correct a software engineer error in a manual entry of a constant value of a roll rate filter, which is the value initially entered in the Inertial Measurement flight software file. The value should have been entered as 1.992476, but was entered as 0.1992476. The incorrect roll rate filter constant zeroed any roll rate data, resulting in the loss of roll axis control, which then caused loss of yaw and pitch control.
What could have been done to prevent the problem? The answer to this question points to lack of organization and control in the software development process.
Why did the software engineer need to manually type the constant value into that file? Well, it turns out that the original file provided by the Control Dynamics group was somehow lost and he had to recreate it from scratch. While human error can be considered as a factor, the primary cause of this one billion dollar disaster was the accidental loss of the original file.
You can view the full story on the Internet at: http://sunnyday.mit.edu/accidents/titan_1999_rpt.doc
This one-billion dollar disaster could have been avoided if the software development team had used a Software Configuration Management (SCM) system that stored all the files safely from accidental loses. However, SCM can do much more than that.
What is Software Configuration Management?
While the rest of this book is focused on the Microsoft Visual SourceSafe 2005 tool, this first chapter is neutral to any SCM tool. In this chapter you will learn the basic terminology and concepts used in the SCM world. If you are already familiar with these concepts you can skip this chapter, although I would still suggest you take a quick look.
First, let me tell you the story of my first interaction with SCM tools and principles. It was during my first job. I was hired along with one of my friends by a small company that had just opened its new software development department. We were the first developers and we had to build an ERP system. All we knew was to write (spaghetti) code. They told us what the application should do and that was it. We were all on our own to make it happen (sounds familiar?). So we scratched our heads and started to write the code. It wasn't long until we needed to work on the same files. We scratched our heads again and came up with a state-of-the-art source management system—manually copying the files from one another. When one person finished the work on a file it was like, "Hey dude, you can take the file now. Oh wait, I must make a backup in case you mess it up." It was like that for a couple of days until we got sick and tired of all the file backups. We had to do something about it.
Then we saw in the Visual Studio suite something called Visual SourceSafe. We told ourselves, "Hey, this thing has something to do with the source files. Let's see what it does!", and installed SourceSafe on our machines. The rest is history. We were now able to work together but independently, without manual file backups, sticky notes, and all that hassle. We never got the chance to experience what would have happened if a third developer had come in before SourceSafe and we had to exchange files between all three of us. It probably wouldn't have been as disastrous as the Titan case but still a serious problem. We thus resolved the source management problem. Now we had to build the ERP system. But that's another story.
SCM was invented to resolve problems of this kind and many more. During the early days of software engineering, the impact of the rapid increases in computer power and the complexity of the problems that could be tackled resulted in the so called "software crisis". This was characterized by an inability to develop software on time, within budget, and within requirements. As a result new ideas, principles, and practices had to be developed. The Software Configuration Management concepts were born.
Software Configuration Management appeared as a solution to software problems, when it was clear that programming does not cover every aspect in software engineering and there was a need for predictability in software development. In this context we can define Software Configuration Management as follows:
Note
Software Configuration Management is the discipline of managing how software is modified and built through techniques including source code control, revision control, object build tracking, and release construction. SCM involves identifying the configuration of the software at given points in time, systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the software development lifecycle.
As you can see from its definition, Software Configuration Management aggregates several different concepts and techniques. You may be familiar with some of them as they can work on their own. But as the whole is more than the sum of its parts; SCM is more than all these techniques used independently.
So, let's start with... the end. What is the software development lifecycle?
The Software Development Lifecycle
The Software Development Lifecycle (SDLC) represents the process used to develop a software system, starting with its conception and ending with its termination.
When developing any software system we adopt a development model. There are many development models, each having its advantages and disadvantages, but one way or another they all employ a succession of basic development phases as follows:
Planning and Specifications: Every activity must start with a plan. Failing to plan is planning to fail. The degree of planning differs from one model to another, but it's very important to have a clear understanding of what we are going to build by creating the system's specifications.
Analysis and Design: In this phase we analyze and define the system's structure. We define the architecture, the components, and how these components fit together to produce a working system.
Implementation: This is the development phase. We start code generation based on the system's design using compilers, interpreters, debuggers to bring the system to life.
Testing: As different parts of the system are completed, they are put through a series of tests. Test plans and test cases are used to identify bugs and to ensure that the system is working according to the specifications.
Releasing: After the test phase ends, the system is released and enters the production environment.
Maintenance: Once in the production environment, the system will suffer modifications as a result of undetected bugs or other unexpected events. The system is evaluated and the cycle is repeated.
SCM provides the way to control the software development lifecycle, allowing for a greater degree of software management being one of the core components in the software development process.
Let's see how SCM helps us control the development lifecycle.
Software Configuration Management Concepts
In order to control the software development lifecycle, SCM employs a series of concepts and techniques. We will take a look at some of these key concepts and techniques, what they are, and how they work. In this section you will learn about the following:
Let's discuss each of these topics, one at a time.
Resource Management
In order to build any system, you need resources. When you build a house, you need bricks, cement, roof, windows, doors, and so on. The same concept applies to software systems. Your resources, however, will consist of source code files, image files, configuration files, and so on (depending on your project type).
Managing resources is an essential aspect in building any kind of system. When it comes to software, these resources must be identified and organized in a way that provides flexibility as well as security. We can achieve this organization by storing the resources in a managed area. This area is commonly referred to as a repository, database, or depot where every resource of the project resides.
The Repository
The repository is the place where all the source code files, images, documents, configuration files, and all the software components concerning the project are stored. In a traditional way, they are organized in a hierarchy of logical files and folders, a virtual file system tree. Security is also enforced because the repository provides a single point of access for everything the project needs in order to be successfully built.
The following figure represents a simplified repository structure:
Typically we create a new repository when we start development on a new product. We create a base project structure and add it to a new repository. The logical repository structure matches the project structure.
Some of the main reasons to have a central repository are:
The best physical location of the repository is on a dedicated server machine as this simplifies repository management and security, and gives an optimal performance. To ensure the maximum operation uptime and disaster recovery, the server should be equipped with:
While RAID systems and UPS are fairly cheap nowadays, if you cannot afford such configuration it is wise to think of other methods of ensuring repository safety. Users sometimes make the mistake of thinking their source code is a hundred percent safe once it has been added to a source control management repository. Creating disk backups of the repository is a smart choice and a must when RAID configurations are not used.
Different SCM systems store the repository using files on the server's file system, a database system, or a hybrid between these two. Apart from the actual resources, a repository must keep resource metadata, or data about the resources such as file history. The metadata grows side by side with the resources in the repository and adds to its size.
Having only one repository may seem a good idea. However keeping many unrelated projects in one repository can have an impact on performance. Many SCM systems are capable of managing multiple distinct repositories. To obtain maximum performance it's better to store resources that belong to different products using different repositories.
Many SCM systems also have remote user support. Remote users can access the repository from thousands of miles away through the Internet using different protocols. However, exposing the server on the Internet presents a high security risk. To protect the server from Internet threats, a firewall must be configured to allow only authorized connections.
So far we have a place to store our software projects. But we need a place to work and develop our projects, and to test our new ideas that might or might not work. For that purpose, SCM systems have workspaces.
Workspaces
While the repository is stored in a central area on the server machine, its users (developers, testers, etc.) work individually on different machines. The SCM system has to provide a workspace area for each of them and be able to synchronize the workspace with the repository when this is required. Different SCM systems name this workspace differently: working folder, working directory, sandbox, view, enlistment, etc.
The purpose of the individual workspace is to provide users with an area where they can work separated from the repository and to isolate each user from the others. This is done in order to prevent one user's changes from affecting the others while they are working. Users make changes to the workspace content, adding, modifying, and deleting files without the worry that they might affect the repository or anybody else for that matter.
To synchronize the workspace with the repository, SCM systems have basic commands that perform actions to:
The actual names for these commands differ from one SCM tool to another but all have them.
The repository starts as an empty storage area for the new product. After creating a basic organization of the project, we add it to the repository using the Add command. This operation adds our initial project structure to the repository from which other users can Get it.
The workspace starts as an image of the repository at a given point in time on the users' machines, having no real new value. They use the Get command to obtain the contents of the repository.
In contrast with the repository, a workspace can get very messy. Tying to implement a new feature or trying to fix a bug can lead to the contents of the workspace failing to even compile. Maybe the changes that at first seemed a good idea don't seem such a good idea after a while. All those changes can simply be discarded and the workspace be recreated from the repository. If, however, the changes are functional, then the workspace suddenly acquires value. As soon as this happens we want to make sure we save these changes in the repository where they are safe and everybody else can see and use them.
Note
Best Practice
Do not let the workspace acquire too much value. Instead, synchronize the changes to the repository as often as possible.
While storing the projects to the latest resource versions, the repository has what a simple storage server doesn't. It has a timeline, a way to keep a record of resource history—resource versioning.
Resource Versioning
A fundamental feature of the repository is its ability to store all the versions of the resources it contains. During the development process, resources in the repository change and evolve as the project evolves. Resources are modified, renamed, and moved from one folder to another, new resources are added, and others are deleted. All these operations are part of the day-to-day work. The repository keeps track of these operations and provides the ability to view its state at any time in the past. It remembers every operation ever performed. If we wish we can view, compare, and restore any old resource version. Unfortunately it cannot provide us with a view of the future, but that's where we come into play, right?
Resource changes are stored by the repository as revisions.
Revisions
Each time a resource is changed and saved back to the repository, a revision is created. Thus, a resource evolves as a succession of revisions, usually referred to by successive numbers such as 1, 2, 3 or 1.1, 1.2, 1.3 etc.
There are two modes of keeping revisions. One is called per-file revision numbering, where every resource has independent revision numbers. Consecutive revisions have different contents.
Another revision mode uses global revision numbering. For each resource change, the entire folder structure is updated with a new revision number regardless of the fact that other resources haven't changed. In this mode, consecutive revisions of a file may, or may not have different contents.
The following figure shows a resource that has evolved over the course of five revisions:
The repository keeps every revision with the ability to retrieve any one of them.
But how does the repository keep resource versions? One simple solution would be to keep a copy of every version of a resource. While this solution is very simple, it has a major disadvantage: as time passes, these copies occupy more and more disk space. This makes repository management harder, lowers performance, and is inefficient.
For example, let's say we have a 1MB file stored in the repository. This may be a document specifying project specifications. Every once in a while we alter this document by making small changes to it. Every revision we create will be about the same size, so after four changes this file could take as much as 5MB. And this is just for one file.
Usually, only a small part changes between successive revisions, so two successive revisions differ only by a small percentage. A cleverer idea would be to save only the difference between the two revisions.
Deltas
The difference between the two revisions is called a delta. Keeping only the delta and not having redundant information allows us to use the storage space very efficiently and increase performance. When getting a resource version, the deltas will be applied against a base version and the resource will be reconstructed at that point in time.
Using deltas, after four small changes, our 1MB document will not take as much as 5MB anymore, adding just the space to save the deltas.
The following figure shows how the latest resource version is constructed using the base version and the forward deltas:
This approach helps in retrieving old versions very fast, but as we retrieve newer versions, more and more deltas have to be combined resulting in greater overhead. As most of the time we retrieve the latest version, we have to deal with this overhead every time.
To overcome this, another approach is to keep the latest file version and use reverse deltas
