Week 3 Flashcards
What is Change Management?
In software development, change management refers to tracking and managing changes to artifacts, like code or project requirements.
What are Change Control items?
- Source code files
- Build scripts or configuration files
- Default application configuration files
- User documentation
- Requirements specifications
- Version control tool configurations
What are not Change Control Items?
- Compiled binaries.
- Third party libraries.
- Compiled document formats, e.g. PDF, PS.
- Auto-generated source code files.
- Client-side IDE configuration.
- Log files.
What is a control system?
Version control, also known as source control, is the practice of tracking and managing changes to software code. Version control systems are software tools that help software teams manage changes to source code over time. As development environments have accelerated, version control systems help software teams work faster and smarter. They are especially useful for DevOps teams since they help them to reduce development time and increase successful deployments.
Main difference between centralized and distributed version control
The main difference between centralized and distributed version control is that, in centralized version control, the versions are saved in the remote repository, while in distributed version control, versions can be saved in the remote repository as well as in local repositories of the local machines.
Centralized Version Control
In centralized version control, there is a set of local computers and a single server. The server operates as the central location. When a developer changes the source code in his local machine, those changes get saved in the central server. The working copy is available in the local machine, but the versions are saved in the server. In other words, the central location manages the versions.
A repository is a storage area that stores source codes. We call the repository of the central server the remote repository. If there is a failure in the central location (server), the developer cannot access the versions. Furthermore, the developer will not be able to access the repository in the central location due to network connectivity issues. These are some drawbacks of a centralized version control system.
Distributed Version Control
Distributed version control provides solutions to the limitations of centralized version control. There is a set of computers and a server. The server has a remote repository. At the same time, each computer has its own local repository. There is no issue of the failure of the server as each machine has a local repository. The repository is distributed among multiple machines. Therefore, we call this a distributed version control system.
Furthermore, in this setup, each developer gets his own repository. He can make a change in the local repository and share it with the other developers. Moreover, there is no interference from other repositories. Each repository track history, perform pushing and pulling changes to other repositories, and supports merging. Besides, if there is no network connectivity, the developer can create versions in his own local repository. He can push the changes to the remote repository when the internet connection is available.
Commits are comprised of?
- Unique id
- 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 such as: Change author, Timestamp and Log message.
Commit Log Messages 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.
Trunk Based Development
Where each developer divides their own work into small batches and merges that work into trunk at least once (and potentially several times) a day. The key difference between these approaches is scope. Feature branches typically involve multiple developers and take days or even weeks of work. In contrast, branches in trunk-based development typically last no more than a few hours, with many developers merging their individual changes into trunk frequently.
Feature Branch Development
Where either a developer or a group of developers create a branch usually from trunk (also known as main or mainline) and then work in isolation on that branch until the feature they are building is complete. When the team considers the feature ready to go, they merge the feature branch back to trunk.
Usually short lived.
Staging Branches
Long lived branches that live in parallel with the master and trunk. All the staging branches are automatically deployed to the UAT Environment (User Acceptance Testing) where users can run manual tests on the system
Naming Conventions for Branches
Following conventions for common branches enhances project maintainability:
- master/trunk
- uat, staging or preprod[uction]
- deploy[ment] or prod[uction]
Use a hierarchical naming strategy for features branches, e.g.
- feature/webapp/splash
- feature/mobapp/login
