The kindest.
Recently, I started reading and reviewing books on my favorite topics - SCM, which primarily includes version control, tracking changes, tweaking and releasing releases and several other equally important topics. At this time, under the distribution got another book
from among those that I chose myself for detailed review. Called
Software Configuration Management Patterns : Effective Teamwork, Practical Integration, the authors are Stephen P. Berczuk and Brad Appleton. It can be translated into Russian as "Software Configuration Management Patterns: Effective Teamwork, Practical Integration."
As in any other field of knowledge, SCM has its own established practices, techniques, and just good ways to make work efficient. Accordingly, someone should have already ordered all this in one source. The authors also have a lot of experience not only software development, but also configuration management, so they took up the task.
')
The theme of patterns in the development of software has been studied for a long time And, as it turned out, it takes its origin from architecture. Sergei Teplyakov not so long ago told
on the pages of RSDN Magazine about the origins of this direction, read (after this note, of course).
The whole book is divided into an introductory part, 2 main sections and a couple of applications.
The introduction and the entire 1st section briefly remind the reader about Software Configuration Management, as well as templates. What is remarkable is that here not only the first-person narration is kept, but quotations from many other works are cited. Authors are often published in journals and conferences. Therefore, there is no shortage of references both to themselves and to other authorities in the industry. In general, the normal scientific approach, it is immediately clear that not only taken from the head, but also at least pondered by other people.
The basis of the book is, of course, the description of the patterns themselves. Each template is given in the same form - the problem situation is described and questions are asked about further actions, then a detailed answer is given. After that, tasks that are associated with the described template but not yet solved (Unresolved issues) are noted, and references to the literature are given where you can read about the described techniques in more detail (Further reading). In general, the right engineering approach.
A total of
16 templates are described, which the authors conventionally divide into 2 sets.
First, there are
Codeline-related patterns , i.e. templates that show how to work with code. These include:
- Mainline - use of the main branch for issuing stable releases and only stable code;
- Active development line - development "on the trunk" with minimal branching and active work;
- Private versions - a branch for the needs of the developer, branches are used for debugging and intermediate results;
- Release line - branching in order to form new releases (1 new release = 1 branch);
- Release-prep code line - the same as the release line, only branching occurs immediately before release to stabilize the work;
- Task branch - branch-to-task;
- Codeline policy - the introduction and maintenance of policies, closely related to the commit of the code and its (automatic) verification;
The second set is
Workspace-related patterns , where they go:
- Private workspace - about the need to allocate to the developer a workspace with the versions of code and environment settings that are needed for work;
- Repository is a repository in which not only versions of the code are stored, but also the tools necessary for working and creating releases;
- Private system build - about the need to allow the developer to rebuild the system without intersecting with the rest of the project participants;
- Integration build - integration builds for combining the work of the participants;
- Third-party codeline - on how to organize versioning third-party dependencies;
- Task-level commit - variation on the theme of task branch;
- Smoke test - about automated testing at each commit to the main or active branch;
- Unit test - with the same name technique;
- Regression test - about the need to conduct regression testing before the delivery of the delta for integration
In general, basic practices that many have already heard or tried.
The remaining applications provide brief descriptions of useful resources on SCM issues and basic tools (however, the information here is somewhat out of date).
The overall result - I want more templates, but already in this form it is a good reference for the right techniques, we must take it.