Geekly Articles each Day
📜 ⬆️ ⬇️

Configuration Management (part 1, introductory)

How to develop large software? It is not a secret for anyone that the need to develop large and complex software products has always been and also always has been independent of the level of technology existing at one time or another. But exploring and analyzing existing approaches to development, I could not answer the simplest questions related to the "correct" development of high-quality programs. One of the simplest questions I asked myself was how to assign version numbers to a released software product. Surely many will agree that this applies not only to large corporate applications, but also to the simplest applications that come from the pen of novice programmers, schoolchildren and students. The meaning of the purpose of versions arises when the program ceases to be an experiment and begins to do something useful. But it is worth noting that even experimental versions of programs make sense to assign a unique identifier. Changing version numbers displays a sequential approach to development and, on the one hand, represents the requirements put forward for the program being developed, and on the other hand, links with previous versions in the form of a common basic functionality or source codebase. We are no longer asking how to develop large software, but try to imagine how to assign versions to our programs. Yes, but what is the connection between these questions? Actually very big.

Before starting the development of any software project, quite a lot of questions should be solved: where to get funding, how many people will work on the project, what time limits should be set, what risks there are and many many others. But this is from a managerial position. From the position of a programmer, questions of another kind are solved: designing an architecture, a database, drawing UML diagrams, and so on. But this is in theory - spend the day to fly in 5 minutes. If we consider all the above steps as stage “0” in the development of a project, then in practice a software project begins with stage number “1” - from development. Suppose this is not entirely correct, but what to do when it is impossible to answer with one of the questions that are posed before the start of development? Even if there are such answers, in one form or another, any software product undergoes evolutionary changes - requirements tend to change. Thus, any software project is subject to difficultly formalized influences, which result in different versions of a product, and this cannot be avoided.

Flexible methodologies (agile methodologies) are known for trying to solve such problems with organizational measures, and this, I must say, is quite successful. But this is an organizational level. The programmer level involves slightly different tasks and problems. It cannot be said that they are not solved at all, but the lack of such decisions, in my opinion, is that they are all solved differently. Even by the same people, but for different projects the same tasks are solved differently. In order to understand what I mean and in order to highlight the essence of approaches to agile development from the point of view of a programmer, I will list the approaches that are commonly used:
  1. Version Control
  2. Automated builds
  3. Unit testing
  4. Static code analysis (static source code analysis)
  5. Documentation generation based on source code (javaDoc, phpDoc, Doxygen, etc.)
  6. Continuous integration (continuous integration)
Usually, development is not complete without using any version control system. All other approaches may or may not be used in individual projects. This already depends on the specifics of the system being developed, many other factors, the most important of which, in my opinion, are the ability to manage all approaches, the availability of the necessary skills and resources, and the need to ensure the quality of the system being developed.
')
As it turned out, there is a separate software engineering discipline that deals with this kind of organizational tasks without reference to methodologies - this is configuration management. Configuration management is the main discipline in determining how the working materials of a software project, the changes made to it, as well as information about the status of individual tasks and the entire project as a whole, are managed and controlled. The success of a project largely depends on how well the configuration management process is organized and this can both save the project and bury it if configuration management does not work well.

The IEEE 610 Glossary describes configuration management as a discipline of applying technical and administrative guidelines (instructions) and controls (monitoring) to: identify and document the functional and physical characteristics of configuration elements; control (management) over changes in these characteristics; recording (saving) and maintaining reports on the processing of changes and the status of their implementation; verification (verification) compliance with the requirements.

But this is a very formal definition. To give you an idea of ​​what this all means, I will simply list the software products and tools that a programmer has to deal with on duty every day:
It so happened that I was so interested in this issue that I even wrote a complete thesis in which I studied the methods and means of configuration management. It also turned out to develop a method that allows you to combine all the tools used (if more precisely, their subset) of configuration management into one platform. If the community seems interesting, then I plan to write a series of articles in which I plan to state how I came to the formalized version control method and try to convey at least partially its essence. I think this will be useful for two reasons:
  1. I will talk a little about the mentioned tools and tools, so to say “from a bird's eye view” in the context of configuration management, I will try to describe their place in the general mosaic of development tools.
  2. Finally, I’ll show you what principles you should follow when assigning release numbers to software products, and try to make this issue more transparent than it is (I suspect for many) now.
In order to stir up interest in subsequent articles, I will tell you a little about the essence of the method. Since configuration management is mainly based on managing the source code repository, it would be logical to assume that in order to coordinate the work of all configuration management tools, it is necessary to formalize the rules of repository maintenance. This should be done in such a way that adopted agreements could be used in any of the constituent elements of the configuration management platform — in build tools, continuous integration tools, and, of course, people. Thus, the repository is structured (each directory of the repository corresponds to a specific content class, which can be located in this directory), and naming templates for directories are also defined. One of the directory templates is a template of the form xxxx, where x is a number. More precisely, the pattern is described by a regular expression of the form \d+\.(\d+|x)\.(\d+|x)(_.*)? . Such a template corresponds to the most common naming system for assemblies and releases to which everyone is used (examples: 1.0.2, 2.3.5, 3.10.23). The difference in the use of this approach to naming in my method is that the dependences of changes in each digit in the naming system from a certain point in time are described formally.

To be continued

References:
  1. svnbook.red-bean.com - About Subversion
  2. martinfowler.com/articles/continuousIntegration.html - what is continuous integration
  3. www.swebok.org - Guide to the Software Engineering Body of Knowledge. The book is about software engineering, one of the chapters of which is devoted to configuration management. Free for download.
  4. www.cmcrossroads.com is a community that focuses on discussion of issues related to configuration management.

Source: https://habr.com/ru/post/53687/

More articles:


All Articles