Configuration Management

4,416 views

Published on

Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life.[1] For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life cycle of an information system.

scmGalaxy.com is dedicated to software configuration, build and Release management. This covers CVS, VSS (Visual Source Safe),Perforce, SVN(Subversion) MKS Integrity, ClearCase,TFS,CM Synergy, Best Practices ,AnthillPro, Apache Ant, Maven, Bamboo, Cruise Control and many more tools.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,416
On SlideShare
0
From Embeds
0
Number of Embeds
273
Actions
Shares
0
Downloads
500
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Configuration Management

    1. 1. Configuration Management www.scmGalaxy.com scmGalaxy Author: Rajesh Kumar [email_address]
    2. 2. Agenda <ul><li>Introduction to software configuration management (SCM), build and release (BnR) </li></ul><ul><li>Initiating CM activities </li></ul><ul><li>Case study - 1.5 hours case study to help participants get a complete view of a CM process in a project. </li></ul><ul><li>SCM tools comparison </li></ul><ul><li>CVS – deep dive </li></ul><ul><li>ANT – basics and advanced tasks </li></ul><ul><li>Automated builds using cruise control </li></ul>
    3. 3. Agenda for session 1 <ul><li>Introduction to software configuration management (SCM), build and release (BnR) </li></ul><ul><ul><li>The need for SCM, BnR in a project lifecycle </li></ul></ul><ul><ul><li>Objectives of a SCM BnR system </li></ul></ul><ul><ul><li>Role of a configuration manager </li></ul></ul><ul><ul><li>Typical activities of a configuration manager </li></ul></ul><ul><li>Initiating CM activities </li></ul><ul><ul><li>Identifying the inventory of configurable items </li></ul></ul><ul><ul><li>Defining a CM plan </li></ul></ul><ul><ul><li>Defining a release traceability with tagging and CR numbers </li></ul></ul><ul><ul><li>Build and build automation </li></ul></ul><ul><ul><li>Introduction to environments, </li></ul></ul><ul><ul><li>Tools used in CM </li></ul></ul>
    4. 4. Objectives <ul><li>Understand the role of a CM </li></ul><ul><li>Understand the type of activities a CM is involved in </li></ul><ul><li>How to initiate and administer CM activities in a project </li></ul><ul><li>Strategies for build, environments and automated builds </li></ul><ul><li>Appreciate what is the list of tasks of a CM and be able to begin working as a CM </li></ul>
    5. 5. Need for Configuration Management
    6. 6. The Rambo developer <ul><li>John Rambo is a single developer of a mid sized project </li></ul><ul><li>A one man team taking care of requirements, design , development, testing and delivery </li></ul><ul><li>He has the whole source code on his machine and he overwrites his code each time a bug is fixed or a new change is brought in </li></ul><ul><li>Application is simple easily testable. Overwriting the same piece of code is a rare occurrence </li></ul><ul><li>Only his hard disk is backed up as a disaster recovery plan </li></ul>
    7. 7. Rambo developer and his woes <ul><li>With increasing complexity the same parts of the code were getting overwritten </li></ul><ul><li>More often than not, business users would request a change in a feature and soon expect to go back to the old feature or expect a mix of old and new features </li></ul><ul><li>John soon finds himself with many requests to revert back to the old code </li></ul><ul><li>Often john finds himself re-writing parts of the same code because of his overwrites </li></ul>
    8. 8. A disorganized team 1 Guys, I heard you have finally cracked the cluster problem!! Congratulations !! What was it? 2 It’s a silly mistake boss!! An old version of the code was over-written which did not serialize the property files. 3 How did the old version get in there? 4 Prakash was trying to debug some problem last week from on-site and he fixed the problem in the old source and pushed them!!
    9. 9. The problems <ul><li>What is missing in these projects? </li></ul><ul><li>How would you solve it? </li></ul>
    10. 10. The problems and solutions <ul><li>Currently there is no code changes being tracked. </li></ul><ul><li>Once a change is made the old code is over written, there is no way to get back to the old code </li></ul><ul><li>There is no release policy that defines what features need to be released </li></ul><ul><li>A code release is unable to show the user the specific set of features that have been released </li></ul><ul><li>A way to track changes and maintain versions of his code. A Version management tool is necessary </li></ul><ul><li>A release policy should be defined </li></ul><ul><li>A release should be done as a unit and not as a set of individual units </li></ul><ul><li>A release document that explains the changes released in each release should be generated </li></ul><ul><li>There should be a way to reproduce all parts of a release when ever required </li></ul>
    11. 11. Role of a Configuration manager
    12. 12. Definitions - wikipedia <ul><li>Configuration Management - The control of changes , including the recording thereof, that are made to the hardware, software, firmware, and documentation throughout the system lifecycle </li></ul><ul><li>Software Configuration Management - set of activities designed to control change by identifying the work products that are likely to change , establishing relationships among them , defining mechanisms for managing different versions of these work products, controlling the changes imposed , and auditing and reporting on the changes made - pressman </li></ul><ul><li>SCM concerns itself with answering the question: somebody did something, how can one reproduce it? </li></ul>
    13. 13. Software Configuration Management <ul><li>“ A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item , and control changes to those characteristics, report change processing and implementation status , and verify compliance with specified requirements” </li></ul>Source: IEEE
    14. 14. Activities involved Management & Planning (SCMP) Software Configuration Management Software Configuration Identification Software Configuration Control Software Configuration Status Accounting Software Configuration Auditing Software Release Mgmt & Delivery
    15. 15. Need for a Configuration Manager <ul><li>With increasing complexity of a system one needs a dedicated person who can manage the changes to a large software unit </li></ul><ul><li>What is complexity of a software system </li></ul><ul><ul><li>Long running projects </li></ul></ul><ul><ul><li>Large teams </li></ul></ul><ul><ul><li>Distributed teams (distributed development) </li></ul></ul><ul><ul><li>Multiple software units that form one large chunk </li></ul></ul><ul><ul><li>Assets related to the code – scripts, test cases </li></ul></ul><ul><ul><li>Assets not related to the code – documents, release notes </li></ul></ul><ul><ul><li>… </li></ul></ul>
    16. 16. What is a CM’s role <ul><li>A configuration manager works with the project leadership to provide an environment that controls, tracks and reports changes made to any unit of information </li></ul><ul><li>Broadly speaking the various buckets of activities that a CM needs to own are </li></ul><ul><ul><li>Identification of configurable items </li></ul></ul><ul><ul><li>Control the changes of these items </li></ul></ul><ul><ul><li>Provide status and reports related to the changes to an asset </li></ul></ul><ul><ul><li>Manage the build, packaging and release of the software units </li></ul></ul><ul><ul><li>Provide a mechanism of traceability from the software units to the root cause of a change or the primary requirements </li></ul></ul><ul><ul><li>Audit the project and ensure that the CM process is being followed </li></ul></ul>
    17. 17. Role of CM at various stages
    18. 18. CM – stage 1 - Identify and establish <ul><li>The first phase of the project </li></ul><ul><li>Along with the project initiation phase, the CM plan needs to be defined </li></ul><ul><li>Most of the tasks in this phase is with respect to definition of a CM plan and establishing the infrastructure for the project </li></ul><ul><li>Processes, templates, naming conventions etc. will need to be defined for the whole team to adopt in the time to come </li></ul>
    19. 19. CM – stage 1 - Identify and establish <ul><li>Objective </li></ul><ul><ul><li>List of CI identified </li></ul></ul><ul><ul><li>Directory structure defined for all </li></ul></ul><ul><ul><li>Tool for version management </li></ul></ul><ul><ul><li>Change control process defined </li></ul></ul><ul><ul><li>CMP defined, reviewed and accepted </li></ul></ul>
    20. 20. CM – stage 2 - Build and release definition <ul><li>Design and development phases defines the code structure, the tools, the frameworks to be used in the project </li></ul><ul><li>CM defines a build strategy for the project </li></ul><ul><li>First cut build should ensure that it integrates well with the version management tool </li></ul><ul><li>Provide automation to obtain a single integrated unit of software that can be used for development and testing </li></ul><ul><li>Iterative process and prioritization is the key </li></ul>
    21. 21. CM – stage 2 - Build and release definition <ul><li>Objectives </li></ul><ul><ul><li>Base line Build script </li></ul></ul><ul><ul><li>Strategy to enhance build script </li></ul></ul><ul><ul><li>Integration of build with version management </li></ul></ul><ul><ul><li>Strategy to release code </li></ul></ul><ul><ul><li>Ability to support various environments </li></ul></ul>
    22. 22. CM – stage 3 - enhance and strategize <ul><li>The development and testing phases bring with it new tools and changes to source code structure </li></ul><ul><li>The build script needs to evolve and automate as many tasks as possible </li></ul><ul><li>Towards the end of the development phase the need to begin a release process would have arrived </li></ul>
    23. 23. CM – stage 3 - enhance and strategize <ul><li>The ability to tag a release and the ability to roll back a release should be available </li></ul><ul><li>In the near future code will move into a maintenance mode. </li></ul><ul><li>The strategy to support multiple branches of code and simultaneous support and enhancements should be thought through </li></ul>
    24. 24. CM – stage 3 - enhance and strategize <ul><li>Objectives </li></ul><ul><ul><li>Enhanced build script </li></ul></ul><ul><ul><li>Integrated build and release process </li></ul></ul><ul><ul><li>Tagging of specific releases </li></ul></ul><ul><ul><li>One shot deployment and roll-back capability </li></ul></ul><ul><ul><li>Reports and data analysis </li></ul></ul><ul><ul><li>Branching strategy </li></ul></ul>
    25. 25. CM – stage 4 - Continuous Improvement and auto-pilot <ul><li>Mostly in administration mode </li></ul><ul><li>The build script and all process have lived their time and proven their capabilities </li></ul><ul><li>Often a full time CM may not be required </li></ul><ul><li>Often this phase is the point to let go of a full time CM </li></ul><ul><li>As with every software asset, continuous improvement is a must </li></ul>
    26. 26. CM – stage 4 - Continuous Improvement and auto-pilot <ul><li>Objectives </li></ul><ul><ul><li>Reports of releases and release notes with each release </li></ul></ul><ul><ul><li>Minor changes to build script </li></ul></ul><ul><ul><li>Ability to regression test and manage releases </li></ul></ul><ul><ul><li>Manage multiple branches and multiple releases </li></ul></ul><ul><ul><li>Focus on traceability from released features to bugs. Control changes to the repository </li></ul></ul>
    27. 27. CM – important tasks
    28. 28. Important tasks <ul><li>Among all the phases a few tasks will be the most important part of a CM’s job </li></ul><ul><li>The next few slides will delve deep into some of these tasks </li></ul><ul><li>The aim would be to understand each of these tasks in detail </li></ul><ul><li>The intent is to provide you with a view of the over all objective of the task and there on to arrive at a few strategies for each of them </li></ul>
    29. 29. Important tasks - list <ul><li>Identify CI </li></ul><ul><li>Version management and tool selection </li></ul><ul><li>Prepare CMP </li></ul><ul><li>Release and Branching strategy </li></ul><ul><li>(Multiple) Environment management </li></ul><ul><li>Build script </li></ul><ul><li>Integrating tools with build </li></ul><ul><li>Audit of the CM process </li></ul><ul><li>Automating builds </li></ul>
    30. 30. Configuration items
    31. 31. Identify Configurable Items <ul><li>What is a Configurable Item (CI) </li></ul><ul><ul><li>A CI, is a unit of configuration that can be individually managed and versioned. </li></ul></ul><ul><li>Term used to describe any entity / asset (code and non-code) that may change across the project phases </li></ul><ul><li>The type of asset and its users will help in defining a versioning strategy and its availability </li></ul><ul><li>A CI list should be a comprehensive list of assets (or asset types) and should feed into the tool identification step </li></ul>
    32. 32. CI list Selectively available to the whole team Usually available to the whole team Access control Rare Never to rare Frequency of updates Single point of lookup Maintains versions MOM and versions of MOM will be crucial during acceptance No Yes Team. Selectively to the client <ul><li>PM assets </li></ul><ul><li>Status Reports </li></ul><ul><li>MOM </li></ul><ul><li>Plans </li></ul><ul><li>Process documents (including CI) </li></ul><ul><li>Bug analysis reports </li></ul><ul><li>Audit documents </li></ul>Helps in base lining the initial artifacts given by the client. Could be crucial during UAT Probably Yes Client / whole team Client supplied documents Charts, reports, existing design documents etc. Need for CM Source code Documents / PDFs/ excel / ppt Audience Asset type
    33. 33. CI list All people internal to the organization and in the project should be given easy access All people involved in a project should be given easy access Access control Very high High Frequency of updates Version management Needs to be used for build and release One point lookup for all source code Yes No Whole team Client may not be granted access <ul><li>Application Source </li></ul><ul><li>Source code relevant to all modules </li></ul><ul><li>Configuration files </li></ul><ul><li>DB scripts </li></ul>Ability to track the assets as they evolve. Need to revert back to versions One point lookup No Yes Whole team and client <ul><li>Project documents </li></ul><ul><li>requirements </li></ul><ul><li>Design and strategy document </li></ul>Need for CM Source code Documents / PDFs/ excel / ppt Audience Asset type
    34. 34. Where to version the CI <ul><li>Choice of network share, internal CVS and an external facing CVS </li></ul><ul><li>Classified reports and sensitive documents may not be shared with the whole team or even the client. </li></ul><ul><li>Access control and level of access should be considered while choosing the location of store </li></ul><ul><li>Use a network share or a private CVS repository </li></ul><ul><li>Different repository for client and internal teams with scheduled synch-up between the two </li></ul><ul><li>A network share is not version sensitive but can be used for static items like 3 rd party software downloads, documentation etc. </li></ul>
    35. 35. Directory structure <ul><li>Over all a directory structure is mostly common sense </li></ul><ul><li>Ability to logically separate out asset types and put them into separate folders </li></ul><ul><li>Based on the version management tool, one can setup directory level permissions or permissions at a repository level </li></ul><ul><li>It may also be prudent to understand the need for private work areas and private folders for each individual in the project </li></ul><ul><li>Leverage the existing structures at an organization / group / account level for a start point </li></ul>
    36. 36. Directory - first level <ul><li><repository name> </li></ul><ul><ul><li>Requirements </li></ul></ul><ul><ul><li>Design </li></ul></ul><ul><ul><li>App </li></ul></ul><ul><ul><li>Templates </li></ul></ul><ul><ul><li>QA </li></ul></ul><ul><ul><li>PM </li></ul></ul><ul><ul><li>UI </li></ul></ul><ul><ul><li>reports </li></ul></ul>
    37. 37. Naming conventions <ul><li>Naming conventions (even if a file is organized into directories), should describe the asset type to the fullest using some meta data of the asset. </li></ul><ul><ul><li>intent of the document (or asset) – GlobalOne_reference_exisitng_report_template.doc </li></ul></ul><ul><ul><li>date (specially with MOM) – MOM_admin_role_clarififcaton_010207.doc </li></ul></ul><ul><ul><li>module it is relevant to – design_admin_logging.doc </li></ul></ul><ul><li>All asset types identified in the CI list should be given a naming convention </li></ul><ul><li>Source code will follow the naming convention given by the coding standards document </li></ul>
    38. 38. Version management tools
    39. 39. Version management tools <ul><li>There are various tools that allow version management </li></ul><ul><li>The primary features of these tools are </li></ul><ul><ul><li>Version management </li></ul></ul><ul><ul><li>Concurrent development (lock or merge) </li></ul></ul><ul><ul><li>Client server model </li></ul></ul><ul><ul><li>Branching </li></ul></ul><ul><ul><li>Tagging </li></ul></ul><ul><ul><li>Multiplatform support </li></ul></ul><ul><ul><li>Integration with IDE </li></ul></ul><ul><ul><li>Multiple authentication modes </li></ul></ul>
    40. 40. Version management tools <ul><li>Some tools provide the following features </li></ul><ul><ul><li>Web interface (integrated with the product) </li></ul></ul><ul><ul><li>Distributed development using multiple repositories </li></ul></ul><ul><ul><li>Auto-replication </li></ul></ul>
    41. 41. Selection criteria <ul><li>Criteria </li></ul><ul><ul><li>Locking and merging </li></ul></ul><ul><ul><li>Authentication and authorization mechanism </li></ul></ul><ul><ul><li>Need for distributed repositories / distributed clients </li></ul></ul><ul><ul><li>Web interface </li></ul></ul><ul><ul><li>Licenses (cost and ease of setup) </li></ul></ul><ul><li>Mostly the client / organization standard will be used as the default for a project </li></ul><ul><li>However, in case we are presented with a ground up scenario, then the criteria listed above can be used for selection of the tool </li></ul>
    42. 42. Various types of repository access <ul><li>Understand the impact of </li></ul><ul><ul><li>Network speed </li></ul></ul><ul><ul><li>Stale data </li></ul></ul><ul><ul><li>Cost of setup </li></ul></ul><ul><ul><li>Security </li></ul></ul><ul><ul><li>Authentication </li></ul></ul>
    43. 43. Version management – version number <ul><li>The basic versioning of an asset will be 1.0 onwards in most version management tools. </li></ul><ul><li>Incremental changes are recorded as 1.1, 1.2 and so on </li></ul><ul><li>From an asset perspective, a version history will be maintained in the asset itself to define the changes made across each released version </li></ul><ul><li>The version numbering at a tool level can be used as is </li></ul><ul><li>Thought should be applied more to tagging of assets and base lining assets </li></ul>
    44. 44. Version management - tagging <ul><li>A tag helps in creating a logical name for all assets within a repository at a particular instance </li></ul><ul><li>A tag can be given at a branch level and based on the tool even at a directory level </li></ul><ul><li>Tagging is the most important feature of a version management tool that helps in recreating a release </li></ul><ul><li>The name of a tag should be intuitive enough to show the user information about the date, version number, major and minor release etc </li></ul>
    45. 45. Files in the repository
    46. 46. Tagging the repository <ul><li>The number of versions that each file take is dependent on each owner </li></ul><ul><li>However, when a delivery needs to be done, all files across multiple versions need to be taken. </li></ul><ul><li>One needs to take these files and have the ability to recreate the version to solve a bug if need be </li></ul><ul><li>Tagging allows us to set a string as the “tag” to various files each with different versions </li></ul><ul><li>A tag is like a snapshot that can be recreated </li></ul>
    47. 47. CMP – configuration management plan
    48. 48. Intent of a CMP <ul><li>A CMP describes the configuration management plan for a project </li></ul><ul><li>Describes the repositories, naming strategy, versioning strategy and more </li></ul><ul><li>Reference point for the team to begin working in a project </li></ul><ul><li>Helps in documenting all the CM activities and delegating responsibilities of a CM activity to team members </li></ul><ul><li>A CM initiates the CM processes and rolls out a process </li></ul><ul><li>It is for the project there on to adhere to it there on. The CMP defines the various roles and their responsibilities </li></ul>
    49. 49. Intent of a CMP <ul><li>To be used by the whole team, the auditors of the project and the new entrants into the team to understand get hold of various assets. </li></ul><ul><li>The tools used and their setup, the process of getting access can be a separate handbook </li></ul><ul><li>The CMP sets the direction and helps in future audits of the project from a CM perspective </li></ul>
    50. 50. Intent of a CMP <ul><li>A CMP should document enough data to help answer the following questions </li></ul><ul><ul><li>What kind of items are CI? </li></ul></ul><ul><ul><li>Where should I put what CI? </li></ul></ul><ul><ul><li>What are the naming conventions for various items? </li></ul></ul><ul><ul><li>What kind of documents should I maintain and what is my responsibility from a CM perspective? </li></ul></ul><ul><ul><li>What is the versioning strategy of any artifact? </li></ul></ul><ul><ul><li>How will project level changes be tracked? </li></ul></ul><ul><ul><li>What is base lining and how will releases be managed </li></ul></ul>
    51. 51. Change management <ul><li>A key task of the CM is to control the changes to an asset </li></ul><ul><li>A change control process defines the monitoring / approval process that allows incorporating changes into a CI </li></ul><ul><li>Requirements, tools, criteria of acceptance etc. are CI that are stored in the repository </li></ul><ul><li>A change in one of them could affect many other assets and the project schedule </li></ul><ul><li>The intent here is not to resist changes, but to allow a controlled way of managing the changes </li></ul>
    52. 52. Change management <ul><li>The CMP should record the ways to track / control the changes to each CI </li></ul><ul><li>if not all at least the critical assets such as requirements, design, acceptance criteria, plan, strategies specific to the project and more should be considered </li></ul><ul><li>Document the ways to accept changes to a particular asset </li></ul><ul><ul><li>bug tracker / email can be a source of change requests. </li></ul></ul><ul><li>The CMP should also call out the person responsible to manage these changes </li></ul><ul><li>This level of clarity in change management ensures that changes to appropriate documents are controlled </li></ul>
    53. 53. Change management <ul><li>Another aspect of change management is the process that one should follow to get a change incorporated </li></ul><ul><li>More relevant to a PM </li></ul><ul><li>However the CM needs to ensure that a CCB has been instituted for the project </li></ul><ul><li>The change management for appropriate assets would need a CCB approval (schedule change / feature list increase) </li></ul>
    54. 54. Read a sample CMP <ul><li>Demonstration of a CMP </li></ul>
    55. 55. Key points in a CMP <ul><li>Ensure that all CI have a repository to go to </li></ul><ul><li>Ensure that all CI have an appropriate location in the repository (directory structure) </li></ul><ul><li>Ensure that each repository identified is backed up and an appropriate person / group is given the responsibility </li></ul><ul><li>Ensure that all CI have an owner (person, group, roles). These owners will maintain the versions of these items </li></ul><ul><li>Most importantly, ensure that the CMP is well circulated and call out the responsibilities in a team meeting or in a short training program </li></ul><ul><li>Do not assume that people will know about their responsibilities. </li></ul>
    56. 56. Rolling out a CM process <ul><li>Rolling out the process, often is taken too lightly and the team is not always in synch with the process </li></ul><ul><li>Identify who needs to be told what and tell them the process using training programs / meetings </li></ul><ul><li>Do not shy away from setting up a meeting each time the team size swells up. </li></ul><ul><li>For large teams, work with each module rather than a large team </li></ul>
    57. 57. Access to the repository <ul><li>A well defined way to setup the client software and integrating it with the IDE should be documented </li></ul><ul><li>Re-use the standard within the organization for a particular type of repository </li></ul><ul><li>The steps could be simple and easy, but do not assume that a team of 10-50 people will know it </li></ul><ul><li>Ensure that a setup document, is available within the repository / network share </li></ul><ul><li>The setup document should speak about </li></ul><ul><ul><li>Where to get the installable (ensure that nobody uses their own versions) </li></ul></ul><ul><ul><li>How to install it (ensure that the installation document has screenshots) </li></ul></ul><ul><ul><li>How to integrate my IDE with the repository (ensure that people to not have copies of the code in their own machines) </li></ul></ul>
    58. 58. Check point <ul><li>At this point, the CM process has been initiated and established </li></ul><ul><li>The team can setup the clients and begin versioning their assets </li></ul><ul><li>The next set of steps is related to building the code and creating a single composite unit </li></ul><ul><li>Keeping the build process aside it is important to understand the concept of release, branching and traceability </li></ul><ul><li>A build process could be a script or a manual one. The intent of the script is to create a comprehensive unit of code that can be released to an environment </li></ul><ul><li>Lets work with the assumption that a build script exists and understand the concept of release </li></ul>
    59. 59. Release Management
    60. 60. Need for a release <ul><li>A single unit of software has many dependencies on other entities </li></ul><ul><ul><li>Database </li></ul></ul><ul><ul><li>Environment parameters </li></ul></ul><ul><ul><li>Application parameters </li></ul></ul><ul><li>Parameters could differ based on the environment the application is being deployed into </li></ul><ul><li>The intent of a release is to build that comprehensive unit and deploy to an environment </li></ul><ul><li>A release could be a manual one, automated one or a blend </li></ul><ul><li>the key point to note is that it should modify all related entities with a particular version of code and allow users to view new features </li></ul>
    61. 61. Notes about a release <ul><li>Important considerations for a release </li></ul><ul><ul><li>The whole software unit should be one single unit (e.g. ear file) </li></ul></ul><ul><ul><li>Ensure that all external dependencies are modified along with a release </li></ul></ul><ul><ul><ul><li>Database </li></ul></ul></ul><ul><ul><ul><li>Properties file </li></ul></ul></ul><ul><ul><li>These modifications can be manual (not preferred), automated script (better), integrated within the application deployment (like an installation exe - ideal) </li></ul></ul><ul><ul><li>Ensure that a set of happy flows are tested before the release is used by everybody </li></ul></ul><ul><li>Release notes should be used to document the “new features” and the “known issues” in a release </li></ul>
    62. 62. Traceability <ul><li>Traceability helps to relate a component to its requirement </li></ul><ul><li>Once the software is released to an environment there is the additional complexity of bugs </li></ul><ul><li>Each change to the software to resolve a bug, should also be traceable to the bug and the requirements / updated requirement (in the form of a bug) </li></ul><ul><li>A change could even be initiated by a review comment. </li></ul><ul><li>All changes to the unit should be traceable to its original cause for change </li></ul>
    63. 63. Traceability <ul><li>This concept of being able to trace back a need or a cause (requirement) from the effect (code base) is traceability </li></ul><ul><li>A cause of change could be a requirement, a review or even a change to design </li></ul><ul><li>A configuration manager needs to enable traceability with the CM processes </li></ul><ul><li>It is up to the team to make adequate comments, put into version history etc to manage the traceability but the infrastructure to bring in traceability is the task of a CM </li></ul>
    64. 64. Traceability in Documents <ul><li>Documents such as requirements or design are generally described in a word document </li></ul><ul><li>These assets are also CI and therefore will be versioned </li></ul><ul><li>The comments while checking them into the versioning tool is important to bring about some level of traceability against time. The comments will be seen in the future to understand why a check in happened </li></ul><ul><li>The version history table in each of these documents provide a better point for tracking the change </li></ul><ul><li>Descriptive version history and more importantly relating these changes to other artifacts in the repository (MOM, status reports) is most important </li></ul>
    65. 65. Traceability with code assets <ul><li>Traceability is most relevant to code assets </li></ul><ul><li>The traceability of a code asset to a requirement or a design is often done using external matrices and code structure </li></ul><ul><ul><li>Package structure </li></ul></ul><ul><li>Documentation of a method can trace back to a design asset </li></ul><ul><li>Traceability to a change / bug resolution is also more important </li></ul><ul><li>This level of traceability is also relevant in a continuous maintenance mode </li></ul>
    66. 66. Traceability and tagging <ul><li>The ideal way to work with release is to first tag the code and then retrieve the code based on that tag </li></ul><ul><li>Between 2 tags (or releases) one can determine the number of changes done to a repository and track the comments against each of these assets </li></ul><ul><li>Ensuring that a comment exists and the comment follows a particular structure is one way of brining in traceability </li></ul><ul><ul><li>E.g. – comment should begin with BUG #NNNNN - <comment> ensures that the user writes the bug number before he checks in the code </li></ul></ul><ul><li>These comments can be used as a way to define the release notes </li></ul>
    67. 67. Strategy for release numbers <ul><li>A tag that is applied to the repository should be self explanatory of the release and can be used as the release number too </li></ul><ul><li>If a different release number and tag number is being used, then a separate document should track the relation between the tag and the release </li></ul><ul><li>A release number should have the following parts to it </li></ul><ul><ul><li>Code base name / app name </li></ul></ul><ul><ul><li>Major release number (sequence) </li></ul></ul><ul><ul><li>Minor / patch release number (sequence) </li></ul></ul><ul><ul><li>Time (day, month, year) </li></ul></ul><ul><ul><li>Type of release (qa, prod, dev, RC) </li></ul></ul><ul><ul><li>Branch name </li></ul></ul>
    68. 68. Demo of release and tagging <ul><li>Demonstrate tagging and obtaining a release </li></ul><ul><li>Demonstrate the ability to trace file changes between 2 releases </li></ul><ul><li>Show the release readiness template </li></ul>
    69. 69. How to support multiple projects / features <ul><li>Once a project is delivered, and tagged, often the next release is decided at a pre-defined interval </li></ul><ul><li>In the interim the developers continue to edit the files to prepare for the next release </li></ul><ul><li>In the interim, if there are bugs on the production release, the files latest files cannot be used to fix them </li></ul><ul><li>At each point where a release is made, once needs to create a branch </li></ul><ul><li>A branch is like a copy of the whole code base except that it starts of from a particular tag / version </li></ul><ul><li>The main branch is called the ‘HEAD’ branch. All other branches can be named as required </li></ul><ul><li>Branches can be merged once it is no longer relevant </li></ul><ul><li>View CodeBranch_Merge.vsd </li></ul>
    70. 70. Note on branching <ul><li>A new branch is more responsibility on the CM and the dev team </li></ul><ul><li>Each bug and change there on should be done on the right piece of code </li></ul><ul><li>Update the setup documents to reflect the steps needed to retrieve sources from a particular branch and not just the main trunk </li></ul><ul><li>Branching as a concept should be taught to novice developers </li></ul><ul><li>Builds and environments to deploy the build is also impacted with each new branch </li></ul><ul><li>Often the number of CM in a project may need to be increased </li></ul>
    71. 71. Branching in CVS
    72. 72. Impact of branching <ul><li>branching of a repository impacts </li></ul><ul><ul><li>Tags </li></ul></ul><ul><ul><li>release process </li></ul></ul><ul><ul><li>frequency of builds </li></ul></ul><ul><ul><li>developer environments </li></ul></ul><ul><ul><li>build scripts </li></ul></ul><ul><ul><li>Setup documents </li></ul></ul><ul><ul><li>Authentication permissions </li></ul></ul><ul><ul><li>Build machine hardware requirements </li></ul></ul><ul><li>Understand the impact of branching for your project </li></ul><ul><li>A new branch is a simultaneous project on the same code base but on different threads. It is simple only if pain is taken early on to strategize </li></ul>
    73. 73. Demo of branching
    74. 74. Supporting multiple environments
    75. 75. Common issues with CM and a team <ul><li>Issues a team often faces with a bad CM </li></ul><ul><ul><li>I do not know how to configure my client environment? </li></ul></ul><ul><ul><li>What is the process to follow when I check in my code? </li></ul></ul><ul><ul><li>What is traceability? What is my role in it? </li></ul></ul><ul><ul><li>The DB does not reflect the latest status, what should I do to get the DB changes into the code base? </li></ul></ul><ul><ul><li>Where is the documentation of the 3 rd party library? May I should download and use the latest version? </li></ul></ul><ul><ul><li>The build takes too long, all I wanted to do was to deploy a JSP page? </li></ul></ul><ul><ul><li>Which environment is the tester getting these bugs? How many environments are there? </li></ul></ul>
    76. 76. Audit of a process <ul><li>Need for audit </li></ul><ul><ul><li>Understand whether the course being taken is as per the original plan </li></ul></ul><ul><ul><li>Deviations are not unnatural, but the impact of deviations should be well understood </li></ul></ul><ul><ul><li>De-risk the process / project to ensure that there are no serious lapses against the plan </li></ul></ul>
    77. 77. SCM audit <ul><li>The purpose of the Configuration audits is to: </li></ul><ul><ul><li>Assure that correct versions of Configuration items are placed under the appropriate directory / folders in the central repository. </li></ul></ul><ul><ul><li>Changes to be included in the version of the product to be delivered are included. </li></ul></ul><ul><ul><li>All required items of hardware, software, system, data, procedures, and documentation are available with correct identification and labeling and storage. </li></ul></ul><ul><ul><li>Configuration Status is tracked </li></ul></ul><ul><li>Show a sample audit template </li></ul>
    78. 78. Frequency of audit <ul><li>Quarterly audits or auditing between phases will keep the process compliance high </li></ul><ul><li>Audit will usually done by PM / Leads from other projects </li></ul><ul><li>Audits within the project is also a good practice </li></ul><ul><li>The CM is the owner of the CMP and has to ensure its adherence </li></ul><ul><li>Regular checks by the CM will help in the long run </li></ul><ul><ul><li>comments when doing a check-in </li></ul></ul><ul><ul><li>maintaining the version history in documents </li></ul></ul><ul><ul><li>adherence to the naming conventions </li></ul></ul>
    79. 79. CM best practices <ul><li>Integrate all users with the repository. Build, development IDE and other touch points should use the repository as the source </li></ul><ul><li>Dissuade users from making copies of the repository items </li></ul><ul><li>Focus on automating as many tasks in the build script </li></ul><ul><li>Automate the build kick off using tools like cruise control </li></ul><ul><li>Manage only the source and not the derived binaries </li></ul><ul><li>Arrive at an appropriate branching strategy for the project </li></ul><ul><li>Roll-out the CM process and educate the team </li></ul>
    80. 80. Mindtree CM’s role
    81. 81. SCMP Process at MindTree
    82. 82. What are PM’s Responsibilities? Conduct internal SCM audits Plan SCM Audit & ensure compliance Train the team Plan SCM related trainings for the team Establish SCM Processes (checkin,checkout,build,release) & ensure compliance Ensure setup of SCM Processes Establish Change Control Process Ensure CCB is established Create SCM Plan Ensure creation of SCM Plan Identify SCM tool Identify SCM tool Identify Configuration Manager CM’s Responsibilities PM’s Responsibilities
    83. 83. What are PM’s Responsibilities? CM’s Responsibilities PM’s Responsibilities Releases (QA, UAT, Production) Setup / Automation of builds Branching Tagging Directory Structure Naming Conventions Baselining Communicate the importance of SCM to the team
    84. 84. Case study
    85. 85. www.scmGalaxy.com Thank You ! Author: Rajesh Kumar [email_address]

    ×