Perhaps one of the few common tool types for all developers is a change control system. During my career, I have used a progression of them:
Deployment size: the number of dependencies increases with deployment size. What is reasonable for a micro-service in a single language for a single deployment is not going to be the same as a monolith created by several languages.
Deployment frequency: If you release once a quarter, you probably will need to be able to make bug fixes on those deployments until the next one. If you have embraced agile and are doing far more frequent releases, you probably don't need to re-create a build from month ago.
Other change control items: Other software version control systems like docker image registries, artifact and build registries, feature flag capabilities may be providing additional version information that must be considered when looking at your source code control.
Your organizational structure: Conway's law applies to version control. For example, one feature of a distributed version control system is that a QA group can run their own fork of a project and control the pull requests that are put into the testing environment.
Your development process: Saving the most important for last, what is your development process? If a build breaks, is that pull request just rejected and development continues? If that pull request already merged and the build stays broken until it's fixed? Can other developers continue work in their local environments or on branches until it's fixed? All of these questions will have different answers and have the most impact on how your organization will be using version control.
Version control and managing the changing of your source code is a universal experience for all professional developers. It will pay dividends to know not only how to use the version control in your environment, but also the features and possibilities that are not being used. Because the only constant is change and the answers of today may not be the right ones for tomorrow.
- SCCS
- RCS
- ClearCase
- CVS and SVN
- Serena Dimensions
- Git (GitLab and BitBucket)
The key features of a version control system are:
- Keeping all versions of a file
- Allowing you to tag or label a set of file versions
- Supporting concurrent editing by multiple people
It's this last item that starts a lot of very passionate points of view. You will hear statements like:
"You should only develop on master"
"You should/shouldn't have a branch for feature development"What you need to keep in mind is that the right answer for a particular development environment will depend on many factors. Let's talk about a few of them.
Deployment size: the number of dependencies increases with deployment size. What is reasonable for a micro-service in a single language for a single deployment is not going to be the same as a monolith created by several languages.
Deployment frequency: If you release once a quarter, you probably will need to be able to make bug fixes on those deployments until the next one. If you have embraced agile and are doing far more frequent releases, you probably don't need to re-create a build from month ago.
Other change control items: Other software version control systems like docker image registries, artifact and build registries, feature flag capabilities may be providing additional version information that must be considered when looking at your source code control.
Your organizational structure: Conway's law applies to version control. For example, one feature of a distributed version control system is that a QA group can run their own fork of a project and control the pull requests that are put into the testing environment.
Your development process: Saving the most important for last, what is your development process? If a build breaks, is that pull request just rejected and development continues? If that pull request already merged and the build stays broken until it's fixed? Can other developers continue work in their local environments or on branches until it's fixed? All of these questions will have different answers and have the most impact on how your organization will be using version control.
Version control and managing the changing of your source code is a universal experience for all professional developers. It will pay dividends to know not only how to use the version control in your environment, but also the features and possibilities that are not being used. Because the only constant is change and the answers of today may not be the right ones for tomorrow.
Comments
Post a Comment