ПОСТРОЕНИЕ МОДЕЛИ РАСЧЕТА ВРЕМЕНИ ВЫПУСКА ДОРАБОТОК ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПОСЛЕ ВНЕДРЕНИЯ СИСТЕМЫ УПРАВЛЕНИЯ РЕЛИЗНЫМ ЦИКЛОМ
Aннотация
В работе предложена математическая модель по расчету времени выпуска нового релиза ПО. Данная модель позволяет оценить разницу до внедрения автоматизированной системы релизного цикла и после. Актуальность предложенной методики обусловлена возможностью ее применения к задаче оценки эффективности информационного комплекса, автоматизируемого процесс релизного цикла.
Объектом исследования является информационный департамент банка, предметом автоматизации – процесс оценки времени выпуска доработок программного обеспечения.
Целью работы является построение модели расчета времени выпуска программных доработок после внедрения системы управления релизным циклом, обеспечивающей регулярное, быстрое и стабильное внедрение новых версий программного обеспечения. Для достижения поставленной цели в рамках работы спроектировано архитектурное решение системы, автоматизирующей процесс релизного цикла; смоделирован новый процесс взаимодействия персонала после внедрения системы релизного цикла; разработан конвейер автоматической доставки ПО в промышленную среду и процесс автоматической упаковки ПО в контейнеры; построена математическая модель расчета времени выпуска доработок программного обеспечения после системы управления релизным циклом.
Для решения перечисленных задач использовалась система Gitlab класса CI/CD, предоставляющая возможность автоматически собирать контейнеры и деплоить их в окружения, и система Deckhouse для оркестровки контейнеров.
Ключевые слова: гибкие методологии разработки, DevOps, Infrastructure as Code (IaC), автоматический релизный цикл, воспроизводимость программного обеспечения, расчет времени выпуска ПО, управление релизным циклом ПО
К сожалению, текст статьи доступен только на Английском
Table 1
List of key problems of a typical architecture (compiled by the author)
№ | Problematic | Suggestions for troubleshooting the problem | Advantages of the proposed solution |
1 | Developers have to spend their time setting up the environment for a new software release: connect to the servers provided to them, transfer code from the repository, build it, and install dependencies [14]. | Closer interaction between the development and administration teams. Creating a single pipeline for assembly | Cost reduction for the development team. On-line change tracking for the admin team |
2 | When configuring an industrial environment, it may be found that the settings for the health of the release from the test environments have not been documented [12], [13]. | Using IaC (Infrastructure as code), a single declarative description of the desired state of the system | Centralized management and modification of server configurations, obtaining the same result on all systems |
3 | The difference between test and industrial server environments, which creates difficulties in administration and the assembly of software images for each architecture [16]. | Using containerization technologies [17]. | Reduction of the number of assembly packages, accelerated image delivery. |
4 | The complexity of managing interconnected software components [15]. | Using container orchestration technologies. | Description of the interrelationships of components as IaC. Managing system deployment through configuration |
Table 2
Comparative analysis of container orchestration systems (compiled by the author)
№ | Criteria | Docker Swarm | Openshift | Deckhouse | K8s [19] |
1. | Easy to install | Corresponds | Частично соответствует | Corresponds | Does not correspond |
2. | Интуитивно понятный пользовательский интерфейс | Частично соответствует | Частично соответствует | Corresponds | Does not correspond |
3. | Easy maintenance | Partially corresponds | Corresponds | Partially corresponds | Partially corresponds |
4. | Bare metal. The ability to install directly on the hardware platform. | Corresponds | Corresponds | Corresponds | Corresponds |
5. | Automatic load balancing | Does not correspond | Corresponds | Corresponds | Corresponds |
6. | The ability to configure centralized auditing in third-party systems | Partially corresponds | Corresponds | Corresponds | Partially corresponds |
7. | Automatic software updates in the cluster and the availability of version control | Does not correspond | Corresponds | Corresponds | Corresponds |
8. | Support for Russian operating systems | Does not correspond | Does not correspond | Corresponds | Does not correspond |
9. | Integration with CI/CD solutions | Partially corresponds | Corresponds | Corresponds | Corresponds |
Table 3
Comparative analysis of CI/CD systems (compiled by the author)
№ | Criteria | Gitlab | Jenkins | TeamCity | Bamboo |
1. | Easy to install | Corresponds | Partially corresponds | Corresponds | Corresponds |
2. | Intuitive user interface | Corresponds | Partially corresponds | Corresponds | Does not correspond |
3. | Easy maintenance | Partially corresponds | Does not correspond | Partially corresponds | Corresponds |
4. | Automatic load balancing | Partially corresponds | Partially corresponds | Partially corresponds | Partially corresponds |
5. | The ability to configure centralized auditing in third-party systems | Corresponds | Corresponds | Corresponds | Partially corresponds |
6. | Support for Russian operating systems | Does not correspond | Does not correspond | Corresponds | Does not correspond |
7. | Integration with versioning solutions | Corresponds | Partially corresponds | Partially corresponds | Partially corresponds |
Fig. 1. Conceptual design of the system (compiled by the author)
Fig. 2. The scheme of Deckhouse operation (compiled by the author)
Fig. 3. Product development speed chart before and after system installation. (compiled by the author)
Список литературы