SCM – Software Configuration Management � Marek Bokes � � � � � � � � � 2006�

SCM – Software Configuration Management � Marek Bokes � � � � � � � � � 2006�

MASARYK UNIVERSITY FACULTY OF INFORMATICS Master’s Thesis SCM – Software Configuration Management Marek Bokes 2006 Declaration I declare that this thesis is the original author’s work; done independently by myself. All the data, information and resources as well as publications used within the work are quoted with a qualified reference to the origin. Supervisor: Mgr. Miroslav Kubásek ii Acknowledgements This way I would like to thank to the thesis supervisor, to Mgr. Miroslav Kubásek, for all the guidelines and willingness. Furthermore, my thanks goes to Udo Weber as well as to Hendrik Hempel for the consultations regarding release management. iii Syllabus Source code and configuration versioning itself as well as labelling technique is wide spread in IT world of software development. The have got full control over release management and consequently over deployment process it requires the proper and suitable usage of a versioning system. Only with full control and appropriate usage a release management can’t became a serious bottleneck of the delivery process. As a solution this master’s thesis project brings comprehensive package – a set of defined approach of software versioning and release management besides cooperation with a bug tracking system on one hand, and tools to follow this approach up, i.e. enable this to happen in praxis, on the other hand. Tools to work with versioning system are provided for both developer and configuration (release) manager for specific platform and versioning system. iv Keywords Software Configuration Management, Source Code Versioning, Software Deployment Approach, Software Release Approach, CVS, Bug-Tracking System (Tool), Software Release, Tag, Label, Revision, Consistency Checking v Preface "Source Control is as much a way of thinking about software development as it is a tool. It can facilitate parallel development and enable developmental isolation, but it can ensure neither. Only by establishing and following through on a strategy can a team use Source Control to its fullest potential " -- The Microsoft Corporation The managed way of source code versioning (also known as source code revision control) is to be assumed as a general methodology of software development nowadays. This all is covered by the software configuration management (SCM), which underlies the general configuration management (CM). Besides project management the area of SCM has quite similar importance. Its absence very likely leads to serious issues during software quality assurance checkpoints or during a delivery process in general. The eventual exposition is increased time to deliver of budget cost. For fix price project this would be a disaster. The amount of resources related to SCM - or CM in general - is quite rich, unfortunately often offers only too general point of view or obvious facts. If one searches for specific and directly applicable methodology he will fail, I assume. My such research and investigation in the area failed either. Rough idea of labels promotion what I’m aware of comes from approach implemented upon versioning system of name Clear Case from the Rational 1 company. The versioning system itself is strictly commercial and expensive, on other hand the details of the approach were not exposed to me or any public due to its proprietary nature. With keeping the SCM’s importance in mind and based on absence of third party solution to use or to build on, this master’s thesis project sets to itself an ambitious aim to provide (if possible) generalized versioning approach and a set of tools to technically support that. 1 Note: The Rational Company developed several tools to support development, mainly to increase code quality; in majority for UNIX system. The company has been bought by IBM. vi Table of contents 1 Introduction ..................................................................................................................................1 1.1 Overview ..........................................................................................................................2 1.2 Terminology .....................................................................................................................2 1.3 Common inappropriate usage of a versioning system ......................................................6 1.3.1 Case study ..........................................................................................................7 2 Source code versioning approach ................................................................................................8 2.1 General assumptions.........................................................................................................8 2.2 Main goals overview ........................................................................................................8 2.3 Actors ...............................................................................................................................9 2.4 Predefined label tags ......................................................................................................10 2.5 Who is applying the label ...............................................................................................10 2.6 Disposition of labels.......................................................................................................10 2.7 When to label..................................................................................................................10 2.8 When to label for a first time..........................................................................................10 2.9 The defect tracking cycle................................................................................................12 3 Preparing a release – deploying with versioning system..........................................................13 3.1 Considerations for following example............................................................................13 3.2 The approach ..................................................................................................................13 3.2.1 Zeroth step – put new release label across repository.......................................13 3.2.2 Step one – extract list of files to be released from bug tracking tool................14 3.2.3 Step two – move the new release label, i.e. promote the revision.....................14 3.2.4 Step three – obtain all files of new release .......................................................16 3.2.5 Step four – build the release package ...............................................................16 3.2.6 Step five – completion......................................................................................16 4 Branching approach ...................................................................................................................17 4.1 General assumptions.......................................................................................................17 4.2 Proposed solution ...........................................................................................................17 4.2.1 When to create a separate repository ................................................................17 4.2.2 How to create a separate repository..................................................................18 4.2.3 How to work with separate repositories – the approach basis ..........................19 vii 5 The tools ......................................................................................................................................20 5.1 General assumptions.......................................................................................................20 5.2 Target versioning system................................................................................................20 5.3 Pre-implementation considerations.................................................................................22 5.3.1 The repository access approach........................................................................22 5.3.2 CVS repository database format - files.............................................................22 5.3.3 CVS repository database format - folders.........................................................24 5.3.4 CVS repository database - location ..................................................................24 5.3.5 CVS local checked out copy admin structures..................................................24 5.3.6 The programming language..............................................................................25 5.4 The implementation........................................................................................................25 5.4.1 Common functionality......................................................................................26 5.4.2 The developer space tool – mklabel .................................................................27 5.4.3 The release-manager space tool – cvs_rcheck ..................................................28 6 The conclusion.............................................................................................................................33 7 Literature and resources............................................................................................................34 A Appendix .....................................................................................................................................35 a. The cvs_rcheck script output..........................................................................................35

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    50 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us