7 rules of hygiene in the management of project releases
Checklist for release management quality.
Release management is made up of several practices, practices more technical and instrumental, but simple, and therefore will be understandable even to those project managers who have grown not from programmers, but from some other area. In addition, almost all of them somehow work on one main idea: the dissemination of information among the project participants.
1. All code passes through the repository. All the pieces of the project, created by the hands of people , should be in the repository. Tests, for example. Or installation scripts. Or system documentation: requirements, specifications, diagrams. Here logs, for example, it is not necessary to put in a repository - you will not need control of versions of logs. How not to put and packaged (compiled) code of your project or documentation, collected by the source code. Because the logs and packages are collected automatically and at any time you can repeat this procedure. In order to repeat the set of logs you need, you need a test script (automatic or manual - the second question), walking along which you will receive the necessary logs from the system. To get the package or compile the code, you should be enough to run one command - the collector command. Maven it will be, make or rake - this is up to you.
2. The team sees changes in the repository. Get a mailing list, subscribe all developers to it, and set up sending messages about changes in the repository and comments to these changes to this list. This is the first step to reviewing the code and a good basis for implementing all other practices of working with the version control system. In addition, the visibility of the events taking place in the project will allow the project participants to learn from each other good approaches. It is only necessary to remember to help with the determination of which approach is good and which is so-so.
')
3. The project is automatically assembled by two teams. The first (and only) command is taken out of the repository, the second is the collector. As a result, you can at any time as quickly as possible and without shamanism get a project ready for publication. If you are preparing a project for conducting tests, then a separate task is created for this by the assembler, which will run all the tests that you have automated.
4. The project has a version. There are branches of development and there are clearly recorded versions of the project. Read more about this in the text How to manage project versions .
4. Bugtracker is used to keep track of tasks. If there is a task, it must match the ticket. Do you have a bugtracker? Teach him to work with tasks, and take it as a rule for yourself - as soon as you set a task for someone, write a ticket about this right away and assign a person responsible for it.
5. Each change in the repository corresponds to a ticket. Ticket number or link to bugtracker specify in the comments to the revision. After that, it will greatly facilitate the debriefing - exactly what changes were made to the project to solve a particular task. When making changes to the repository, indicate in the comments to the corresponding ticket the revision number corresponding to this change. As a result: one change - one ticket. You should not make several changes to the repository at once and thereby solve several tickets, this will complicate the study and analysis of the changes made.
6. The project has a Changelog - a history of project changes from version to version. The data in it is up-to-date (even better, it is collected automatically, for example, by a bugtracker), team members know where to find it, how to use it.
7. The project is updated automatically. The installation of the combat code should be able to be updated as well as roll back to the previous version without any data loss. In addition, it is desirable that this can be done as automated as possible. The less time idle renewable service, the more thick and silky hair will be on the head of the project manager.
Release management is made up of several practices, practices more technical and instrumental, but simple, and therefore will be understandable even to those project managers who have grown not from programmers, but from some other area. In addition, almost all of them somehow work on one main idea: the dissemination of information among the project participants.
1. All code passes through the repository. All the pieces of the project, created by the hands of people , should be in the repository. Tests, for example. Or installation scripts. Or system documentation: requirements, specifications, diagrams. Here logs, for example, it is not necessary to put in a repository - you will not need control of versions of logs. How not to put and packaged (compiled) code of your project or documentation, collected by the source code. Because the logs and packages are collected automatically and at any time you can repeat this procedure. In order to repeat the set of logs you need, you need a test script (automatic or manual - the second question), walking along which you will receive the necessary logs from the system. To get the package or compile the code, you should be enough to run one command - the collector command. Maven it will be, make or rake - this is up to you.
2. The team sees changes in the repository. Get a mailing list, subscribe all developers to it, and set up sending messages about changes in the repository and comments to these changes to this list. This is the first step to reviewing the code and a good basis for implementing all other practices of working with the version control system. In addition, the visibility of the events taking place in the project will allow the project participants to learn from each other good approaches. It is only necessary to remember to help with the determination of which approach is good and which is so-so.
')
3. The project is automatically assembled by two teams. The first (and only) command is taken out of the repository, the second is the collector. As a result, you can at any time as quickly as possible and without shamanism get a project ready for publication. If you are preparing a project for conducting tests, then a separate task is created for this by the assembler, which will run all the tests that you have automated.
4. The project has a version. There are branches of development and there are clearly recorded versions of the project. Read more about this in the text How to manage project versions .
4. Bugtracker is used to keep track of tasks. If there is a task, it must match the ticket. Do you have a bugtracker? Teach him to work with tasks, and take it as a rule for yourself - as soon as you set a task for someone, write a ticket about this right away and assign a person responsible for it.
5. Each change in the repository corresponds to a ticket. Ticket number or link to bugtracker specify in the comments to the revision. After that, it will greatly facilitate the debriefing - exactly what changes were made to the project to solve a particular task. When making changes to the repository, indicate in the comments to the corresponding ticket the revision number corresponding to this change. As a result: one change - one ticket. You should not make several changes to the repository at once and thereby solve several tickets, this will complicate the study and analysis of the changes made.
6. The project has a Changelog - a history of project changes from version to version. The data in it is up-to-date (even better, it is collected automatically, for example, by a bugtracker), team members know where to find it, how to use it.
7. The project is updated automatically. The installation of the combat code should be able to be updated as well as roll back to the previous version without any data loss. In addition, it is desirable that this can be done as automated as possible. The less time idle renewable service, the more thick and silky hair will be on the head of the project manager.
Source: https://habr.com/ru/post/4027/
All Articles