Change Management

Change management in the context of software development refers to the systematic approach to dealing with change, both from the perspective of an organization and on the individual project level. It encompasses methodologies, technologies, and capabilities that help manage changes in IT environments, ensuring that changes introduced to software products are implemented smoothly and successfully while minimizing negative impact on services and users.

Key Aspects Include:

Planning: Effective change management starts with planning. This includes defining clear processes and procedures for handling changes, including how changes are logged, evaluated, authorized, and implemented.
Impact Analysis: Before changes are made, their potential impact on the system and stakeholders is thoroughly analyzed. This helps in understanding the consequences of the change and in preparing mitigation strategies if the changes have broad implications.
Communication: Transparent communication is critical. Stakeholders should be informed about the nature of the change, the reasons behind it, and the expected outcomes. This ensures that everyone affected by the change understands what is happening and why.
Implementation: The actual deployment of changes should be meticulously managed. This often involves scheduling changes to minimize disruption, testing changes before full-scale implementation, and having rollback plans in case the change fails.
Review and Continuous Improvement: After implementing a change, it is crucial to review its effects. This review should ascertain if the change has achieved its goals and should identify areas for improvement in the change management process itself.

Change Control Items

In general, any item that is directly edited by a member of the software team is an example of source control item. Anything that is generated from these items is not.

However, the advent of continuous delivery, DevOps, virtualisation and infrastructure as code has meant the configuration files that manage environments can be placed in version control.

Things that are:

Source code files
Build scripts or configuration files
Default application configuration files
User documentation
Requirements specifications
Version control tool configurations

Things that are not:

Compiled binaries
Third party libraries
Compiled document formats, e.g. PDF, PS.
Auto-generated source code files
Client-side IDE configuration
Log files

Version Control System (VCS)

Revision/version/source change/control systems/repositories are a type of software tool for concurrently managing the history of changes to a source code base. All VCS tools share the same common workflow:

make local changes
Receive updates from remote repository
resolve conflicts
submit local changes to remote repository

Overall, the choice between centralized and distributed VCS depends on the specific needs of the project and the team’s workflow preferences. DVCS offers more flexibility and robustness, making it popular in open-source and large-scale projects, while centralized VCS remains effective for smaller teams or corporate environments where tight control over the workflow is needed.

Centralized Version Control Systems (VCS)

Centralized version control systems are based on a client-server model where all files and historical data are stored on a central server. Developers check out files to their local machine, work on them, and then check them back into the central repository. This model simplifies administration and backups since everything resides in one place. A common example of centralized VCS is Subversion (SVN).

Centralized VCS:

Pros:
- Simplified management as there’s only one repository to back up.
- Easier to enforce security policies and access controls.
- Generally simpler for beginners to understand and use, especially in smaller teams.
Cons:
- Single point of failure; if the central server goes down, no one can collaborate or save version history changes.
- Less flexible and slower to adapt to changes due to the centralized structure.
- Handling large binaries and huge repositories can be less efficient.

Distributed Version Control Systems (DVCS)

In distributed version control systems, every contributor has a complete local copy of the entire repository, including all files and revision history. Changes are made locally and then pushed to shared repositories. This approach enables multiple developers to work independently on the same project without constant connectivity to a central server. Git and Mercurial are popular examples of DVCS.

Distributed VCS:

Pros:
- Allows full offline work capabilities, enhancing productivity as developers can commit, branch, and merge locally.
- Reduces the risk of a single point of failure since each clone is a full backup of the repository.
- Encourages branching and merging, fostering more diverse workflows and innovation.
Cons:
- Can be more complex to understand and manage, especially with large teams.
- Requires more discipline and understanding of its complexities to avoid repository history pollution.
- Initial cloning of a repository can be bandwidth-intensive, especially for large projects.

Commit

A commit can be thought of as either the package of information needed to describe how a project has been changed since the previous commit; or as a complete snapshot of the state of the project at that time.

Distributed Version Control Systems (DVCS) use a hashed id, but Centralized Version Control Systems (VCS) just increment a count.

Format

Comprises:

Unique id:
- Hash of:
  - parent IDs
  - author
  - timestamp
  - log message
  - changes
Id(s) of the parent commit(s)
The changes to existing change control items
Any added change control items
Any removed change control items
Metadata
- Change author
- Timestamp
- Log message

Log Messages

For good practice a message should:

Have a short, meaningful title
Describe the intent of the commit
Link to the issue in the project issue tracker or merge request
Explain how the commit addresses the issue

Avoid multiple purposes in a single commit Explain why the commit is being made

Consider configuring a message editor in your git terminal, and implementing a commit message template to encourage consistency