Software configuration management (SCM) refers to a series of measures to control and standardize software products and their development process and life cycle through technical or administrative means at each stage of the development process. The goal of configuration management is to record the evolution process of software products and ensure that software developers can obtain accurate product configurations at all stages of the software life cycle.
What is Software Configuration Management? Benefits of Software Configuration Management
Regarding what is the scope of work of a software configuration management engineer, we must first understand what is software configuration management.
According to Baidu's entry "Software Configuration Management" (partial):
Software Configuration Management (SCM) is a technique for identifying, organizing, and controlling modifications. Software configuration management is applied throughout the software engineering process. Change is inevitable when software is built, and change exacerbates confusion among software developers on a project. The goal of SCM activities is to identify changes, control changes, ensure that changes are implemented correctly, and report changes to other interested parties. In a sense, SCM is a technique for identifying, organizing, and controlling changes in order to minimize errors and maximize productivity.
Software Configuration Management (Software Configuration Management), also known as software form management, or software construction management, referred to as software form management (SCM). Define the components of the software, manage the changes of each project (version control), and maintain the version association between different projects, so that the content of the software at any time during the development process can be traced, including certain significant combinations.
1. What is software configuration management
Then the scope of work of a software configuration management engineer is very clear. Let's take a "XX financial management system" as an example to illustrate:
1.1 Manage all documents of this system (research documents, requirements analysis documents, design documents, test documents, maintenance documents, customer feedback documents, etc.), all codes (including basic codes, comments, sub-version and updated version codes), all Database (with test data, demo data, simulation data, etc.).
1.2 Manage all versions and updated versions of the system and their research and development and derivative basis.
1.3 Manage the test environment of all versions and updated versions of the system. For example, the type and level of the operating system (Linux, UNIX, MAC, iOS, Android, Windows98, Windows ME, Windows2000, Windows XP, Windows2003, Windows VISTA, Windows7...) for the comprehensive test operation, the disk media for the comprehensive test operation (FAT, FAT32, NTFS...), fully tested database systems (Oracle, Sybase, DB2, SQL Server, MySQL, ACCESS, Sybase Anywere...) and more.
1.4 Manage all bugs in this system, and try to reproduce the environment where they appear; manage all unexpected situations reported by customers in this system and the handling plans of the maintenance department and development department.
1.5 Manage the new accounting system, new accounting subjects, and accounting methods and standards promulgated by the state finance department.
To understand what software configuration management is, we must first understand what a configuration file is.
2. What is a configuration file?
The configuration file is used to store some information of related software, such as initialization information, initial path and account, etc., to facilitate the transplantation of the program.
According to the shape of the configuration file, it is divided into the following categories:
In terms of development language, it is hard code, that is, the data configured in the software is directly written in the code, such as: path, IP, waiting time, etc. This method is not conducive to data modification, but on the other hand, if some data is important and fixed, hard coding can protect such data from being modified.
2.2 File Type
The file type is a commonly used method in the current single application architecture. The source code and the configuration file are managed separately. The program reads the file content in the specified directory to load the configuration information when it starts. This method is very conducive to the promotion of products, that is, when the program runs in different environments, it does not need to modify the code, but only needs to change the configuration file. For example, in the test environment, it needs to connect to the 192.168. , you need to connect to the 192.168.1.2:3306 database, then you only need to change the configuration file.
2.3 Database Type
We generally store configuration information in non-text form in the database. This configuration is generally functional and business configuration, which can be dynamically changed, such as function switches (after new functions are launched, they are hidden first, and when they can be released, Modify the data in the database to open the function page).
2.4 Remote call type
The remote invocation type means that all configurations are centrally managed, and the configuration is loaded through the interface when all services start or run, which is the way we are familiar with the configuration center.
3. According to the type of loading, it can be divided into:
3.1 Single Load Type
The initial configuration read when the program starts, generally does not change, such as the credentials information for connecting to the database.
3.2 Dynamically loading types
When the program is running, the configuration information changed according to business requirements, such as function switch, log level, etc.
4. Why apply (software) configuration management?
With the development of digital transformation, offline business is gradually becoming online, the number of applications is increasing day by day, and the application architecture is also becoming more diversified and complex, which also puts forward higher and higher requirements for application configuration.
Initially, the configuration information is hard-coded in the code and placed in the source code repository together with the code; for the convenience of security and management, the configuration is separated from the code in the form of a file for management, and some methods are to distribute the configuration file to the target. The directory on the machine is read directly when the program starts. In some ways, when CI is packaged, the configuration file is entered into the package when different environments are promoted, and the configuration is read from the relative directory when the program is decompressed and run.
The characteristics of these methods are that the configuration changes slowly, and the service needs to be restarted after the configuration change. Therefore, in the stage of a single application with a small number of applications and a simple architecture, it can fully meet the needs of the business. However, with the advent of the microservice stage, especially the arrival of containerized applications, the number of service nodes has grown exponentially, and the management and configuration in the above-mentioned way cannot meet the needs of the business. At this time, the application (software) configuration center came into being.
5. What is application (software) configuration management?
To put it simply, the configuration information is centrally managed and controlled. Of course, with the development of the business and the complexity of the application architecture, there are also many functional requirements for the configuration center, but generally speaking, at least the following requirements need to be met:
5.1 High availability: All configuration information is centrally managed, and the importance of the configuration center is self-evident.
5.2 Real-time: Business requirements need to be notified of configuration updates to the client as soon as possible, such as blue-green release, active-standby switching and other scenarios.
5.3 Multi-environment multi-cluster management: The main scenario of the configuration file is to support the running of the same program in different environments, so the management of the environment needs to ensure isolation and unified management. Many applications also require multi-cluster deployment, so the management of multi-cluster is also very necessary.
5.4 Governance: configuration version control, configuration audit, configuration permission control, configuration grayscale release, etc.
Some people may ask: Hot reloading is also a very common functional scenario of the configuration center. In fact, the hot reloading of the configuration depends on whether the application supports the hot reloading of the configuration. If the application loads the configuration in the memory, there is no way other than restarting the process. If the configuration in the memory can be changed, then it cannot do anything for the configuration center. The core responsibility of the configuration center is to quickly notify the target client of the configuration change.
6. What are the benefits of software configuration management?
Software Configuration Management (SCM) is a technique for identifying, organizing, and controlling modifications. Software configuration management is applied throughout the software engineering process. Change is inevitable when software is built, and change exacerbates confusion among software developers on a project.
The goal of SCM activities is to identify changes, control changes, ensure that changes are implemented correctly, and report changes to other interested parties. In a sense, SCM is a technique for identifying, organizing, and controlling changes in order to minimize errors and maximize productivity.
Software configuration management, which runs through the entire software life cycle, provides a set of management methods and activity principles for software development. Software configuration management is of great significance to both software enterprise managers and R&D personnel.
Requirements: What do users want to do with the software Analysis: What do I want users to want, and how do I make the products that users want. Design: There are several solutions that can be implemented, which is the easiest, which best meets the user's requirements, and how to optimize the integration. Realization: According to the existing design, realize the coding of the module function, and realize the function. Test: black box, white box, and automated tools for functional testing. Look for bugs and imperfections. Operation and maintenance: Repair the imperfect system or bugs in use to make the software run normally. It is really false to say so much, and it is really different from doing it.
7. What does the software configuration management specification include?
Software configuration management is a work that runs through the software development process. For a software project, the software configuration management specification includes at least the following:
7.1 Configuration items and their naming rules.
7.2 Configure the library file directory structure.
7.3 Definition of roles and permissions.
7.4 Configuration item change process.
7.5 Configuration item release.
7.6 Baseline Definition and Baseline Changes.
The baseline in the project has two aspects: one is the baseline as a milestone; the other is the baseline of the staged achievement of the module (for work products), generally avoid changing the baseline. For these two different baselines, the scope of influence is different, and the ways of establishing and changing are also different.
The project's baseline change control committee is composed of customer representatives, product managers, project managers and technical managers. Changes to the released milestone baseline must be confirmed by the change control committee and recorded by QA. All configuration items affected by the change need to be Publish again after resynchronizing; and for baselines that are only kept as working status, generally only the team that established the baseline needs to confirm the changes and record them in QA.