comp3521 Ch25

Configuration Management (CM)

• CM manages evolving software systems by incorporating changes in a controlled manner and maintaining detailed records.
• CM is essential for team projects to manage changes made by different developers.
• CM addresses the challenge of tracking changes and component versions integrated into each system version.

CM Activities

• Version management tracks and manages multiple versions of system components, preventing interference between changes made by different developers.
• System building assembles program components, data, and libraries, then compiles them into an executable system.
• Change management tracks change requests from customers and developers, assesses costs and impact, and decides on implementation.
• Release management readies software for external distribution and monitors the system versions released for customer use.

Agile Development and CM

• Agile development relies on CM tools because components and systems change frequently (several times per day).
• Developers copy definitive component versions held in a shared project repository into their workspaces.
• Developers modify code, use system-building tools to create a test system on their computers, and return the modified components to the project repository.

Development Phases

• The development team manages software configuration and adds new functionality during the development phase.
• A system testing phase releases a version internally for testing, focusing on bug fixes, performance enhancements, and security vulnerability repairs, rather than new functionalities.
• The release phase delivers the software to customers, and new versions are developed to fix bugs, address vulnerabilities, and incorporate new features.

Multi-Version Systems

• Large systems rarely have just one "working" version.
• Multiple versions of a system exist at different development stages.
• The development of different system versions may involve multiple teams.

CM Terminology

• Baselines are collections of component versions forming a system, which are controlled and cannot be changed, allowing recreation from their components.
• Branching creates a new codeline from a version within an existing codeline; the new and existing codelines then evolve separately.
• A codeline comprises a set of versions for a software component and its dependent configuration items.
• Configuration control ensures system and component versions are recorded and maintained for managed changes, identified versions, and storage throughout the system's life.
• Configuration items/Software Configuration Items (SCI) refer to anything under configuration control, like designs, code, test data, or documents, with potentially many versions and a unique name.
• Mainline is a sequence of baselines representing different system versions.
• Merging creates a new software component version by merging separate versions across different codelines, potentially originating from a common branch.
• Release refers to a system version made available for use by customers or internal users.
• A repository serves as a shared database for software component versions and their change metadata.
• System building creates an executable system version by compiling and linking appropriate component and library versions.
• A version is a specific instance of a configuration item differing from others, with a unique identifier.
• Workspace is a private area for software modification without impacting other developers.

Version Management

• Version management tracks different versions of software components or configuration items and the systems using them.
• It ensures the changes by different developers do not cause interference.
• Version Management manages codelines and baselines.

Codelines and Baselines

• A codeline is a sequence of source code versions.
• Codelines apply to system components with different versions for each component.
• A baseline is a specific system definition.
• The baseline specifies component versions, libraries, and configuration files included in a system.

Baselines

• Baselines are specified in a configuration language to clarify included components in a specific system version.
• Baselines facilitate recreating specific system versions like individual system versions for various customers.

Version Control Systems

• Version control systems identify, store, and control access to different component versions.
• Centralized systems use a single master repository. Subversion exemplifies a centralized version control system.
• Distributed systems allow multiple component repository versions at the same time. Git is a distributed version control system.

Key Features of Version Control Systems

• Features include version and release identification, change history, independent development support, project support, and storage management.

Public Repository and Private Workspaces

• Version control systems use a project repository and private workspace to prevent interference and allow independent development.
• The project repository stores the master version of all components & creates system-building baselines.
• Developers check out components from the repository into their workspace to modify copies.
• The changed components are checked back into the repository when the changes are complete.

Centralized Version Control

• Developers check out components from a project repository to a private workspace, then check in changed components back.
• If multiple developers work on the same component, only one checks out a component at a time; others are warned if they try to check out components already checked out.

Distributed Version Control

• A main repository resides on a server containing code from the development team.
• Instead of checking out files, developers clone the project repository.
• Developers operate on required files and maintain new versions on their machine in a local repository.
• Developers commit and update their server when done and push changes to the project repository.

Benefits of Distributed Version Control

• Provides a repository backup.
• Work can continue if corruption occurs, and the local copies can restore the project repository.
• Developers can work offline and commit without an internet connection.
• Compiling and testing an entire system, where developers can test changes on local machines, has project support.

Open-Source Development

• Distributed control is essential for open-source development since many people can simultaneously work on a system without central coordination.
• The public server repository maintains new component versions, while the open-source system manager decides what to pull into the definitive system.

Branching and Merging

• A component may have independent sequences, not just a linear one.
• Developers often work independently on different source code versions.
• The branch needs to be merged at the final stage to include all implemented changes.
• Component versions can automatically merge if there were different code parts.

Storage Management

• Storage management was a vital version control system function when first developed.
• Disk space was expensive, so minimizing disk space was essential.
• The system stores the differences (deltas) between versions and recreates with a master version.

Storage Management in Git

• Git employs a faster approach because the disk is more affordable.
• Git uses a common compression algorithm on stored files instead of deltas.
• Instead of storing file copies, it decompresses files without complex operations.
• Git uses smaller packfiles combined into an indexed file.

System Building

• System building creates a complete, executable system using system components, external libraries, and configuration files.
• System building and version management tools communicate during the build using versions from the version management system.
• The configuration description is also used by the system building tool.

Build Platforms

• The development system refers to tools like compilers and source code editors. Developers check out code before implementing changes.
• The build server builds executable versions that may rely on external libraries not in the version management system.
• The target environment is the platform where the system is executed.

Build System Functionality

• Build script generation, version management system integration, and minimal recompilation.
• Includes executable system creation, test automation, reporting, and documentation generation.

System Platforms

• The development system encompasses development tools like compilers and source code editors.
• The build server builds system versions. This server has the definitive versions.
• The target environment, the platform where the system is executed, may be simple for embedded systems.

Agile Building

• Check out the mainline system from the version management system into the developer's private workspace.

• Build the system and run automated tests to ensure that the built system passes all tests. If not, the build is broken and you should inform whoever checked in the last baseline system. They are responsible for repairing the problem.

• Make the changes to the system components.

• Build the system in the private workspace and rerun system tests. If the tests fail, continue editing.

• Check the system into the build but do not commit a new baseline once it passes its tests.

• The build server rebuilds the system to check for modified components, and if found, edit in the private workspace.

• If the tests persist after the build on the build server, commit it to the mainline as a baseline.

Pros and Cons of Continuous Integration

• Frequent integration finds and resolves problems between developers.
• The latest mainline reflects the definitive system, and if very large, building and testing take too long, particularly with other integrations.
• Test limitations occur if a particular target platform isn't available.

Daily Building

• The delivery time is set for 2 pm.
• New software versions must be sent by the set delivery time.
• Compiling and linking them creates new versions.
• The new version is delivered to the test team, performing predefined tests.
• Faults are returned to developers to repair.

Minimizing Recompilation

• System-building tools should minimize required compilation.
• It checks for a compiled component version to evade recompilation.
• A unique signature identifies and changes source or code versions when edited.
• Comparing source signatures determines object code component generation.

File Identification

• Modification timestamps are time and date when codes are modified. If modified after the object file, recompilation is necessary.
• Source code checksums, a unique number calculated from data, generate a different checksum with just 1 change.

Timestamps vs Checksums

• Timestamps connect via name instead of explicit signature. Building different component source versions in a directory isn't generally possible due to object files sharing names.
• Checksums do not use code-overwriting object code in recompilation. A new object file is generated and tagged. Parallel compilation and component versions can also compile simultaneously.

Change Management

• During a system lifetime, organizational requirements and environment requirements may change.
• Change management ensures system evolution is managed, giving priority to urgent, cost-effective changes.
• The change management process analyzes costs/benefits of proposed changes and tracks modified system components.

Factors in Change Analysis

• Consequences and benefits of change alongside users affected versus costs and the product release cycle.

Change Management and Agile Methods

• Customers are directly involved in change management within agile methods.
• Customers suggest changes alongside the team to assess and prioritize within the system.
• Programmers modify the code while factoring software improving frequently.

Release Management

• A system release distributes software to customers.
• Mass market software typically has two release types: major for significant new functionality and minor for customer issues and bugs.
• Custom software often requires that releases be made on a per-customer basis.

Release Components

• Besides the executable code, releases can have configuration files, data files, installation programs, system documentation, and release packaging/publicity.

Factors Influencing System Release Planning

• Releasing new software is a factor that provides a competitive advantage.
• Competition can be lost from a lack of new features.
• The marketing department may have already committed to release dates.
• Releasing often results in having a new operating system version or fault repairs, whereas minor faults should be issued using Internet patches instead.

Release Creation

• The version control recognizes what can be executable versions.
• Configuration descriptions clarify different hardware or operating systems.
• Update instructions aid customers setting up.
• Installation programs often need scripts implemented from webpages linking to documentation.
• Once this information is available, hand it over for distribution or in sales outlets.

Release Tracking

• In case of problems, the software must be reproduced.
• A release must be documented and created exactly in future versions.
• Customized systems embedded in machines, customers change the specific software versions.

Release Reproduction

• To document releases, record the source code versions used
• Keep file copies of code files, configurations, and data.
• Record OS versions library compilers and building tools.

Release Planning

• Advertising, publicity, and marketing strategies must convince customers to buy the new version.
• Pay attention to releases: Hardware upgrades or frequent systems may defer potential buyers. If system releases are too infrequent, market share dwindles.

Software as a Service (SaaS)

• SaaS (Software as a Service) streamlines release management/installation and allows software developers to replace releases for all customers.

Key Points

• Configuration management teams must make the necessary modifications, incorporating a CM into every action.
• The organization must maintain details of the versions, builds, management, and release of the software.
• Version must keep track of the variations and stakeholders and decide whether changes will be applied via a stakeholder customer.