Динамічне середовище розробки - що це
Місцезнаходження: Головна »З практики» Динамічне середовище розробки - що це?
У багатьох наших проектах загальноприйнято, що ми працюємо з кількома працівниками одночасно над кількома розробками. Ось чому часто трапляється, що два або більше завдань розробляються паралельно, але перевіряються або затверджуються незалежно одне від одного. Ми розповімо вам, чому ми вирішили використовувати динамічне середовище розробки для вирішення цієї проблеми:
Як ми працювали до цього часу: Центральні приймальні системи
В основному, ми створюємо окрему гілку в Git для кожного завдання, а це означає, що паралельне тестування та затвердження не є проблемою. Однак для багатьох проектів у нас є лише одна центральна система прийому. Потім у цій системі прийому можна відтворити лише одну гілку за іншою. Наприклад, якщо прийняття розробки затримується через відсутність працівника або відповідальної контактної особи у замовника, усі подальші розробки поки що блокуються, і весь проект зупиняється. Це не тільки призводить до затримок у загальному проекті, але й до незадоволення наших співробітників.
Щоб ми могли в майбутньому розігрувати кілька гілок одночасно, було потрібно кілька систем прийому. З цією метою ми вже розробили концепцію динамічного середовища розробки на TYPO3Camp Rhein-Ruhr 2017.
Як працюють середовища динамічного розвитку?
На основі Docker та Kubernetes ми спочатку створили власний кластер для контейнерів Docker.
Gitlab CI бере на себе контроль над динамічними середовищами розробки. З кожним натисканням гілки робота в конвеєрі Gitlab CI створює нову версію образу Docker. Зображення для Docker створено спеціально для гілки та включає, серед іншого, усі артефакти та сам проект.
Потім середовище розробки запускається або оновлюється за допомогою команди Slack або безпосередньо через Gitlab CI. Якщо ми видалимо гілку, конвеєр зупиниться в Gitlab CI. Перш ніж конвеєр зупиниться, робота зупиняється та видаляє середовище розробки.
Переваги та недоліки середовищ динамічного розвитку
Найбільша перевага, очевидно, полягає в тому, що ми маємо власну систему затвердження кожного завдання в проекті. Це означає, що тестування та прийняття паралельних завдань уже не проблема. Керівникам та розробникам проектів не потрібно більше витрачати час на розігрування та тестування завдання. Особливо в проектах замовника, в яких багато розробок та підпроектів часто працюють одночасно, ми змогли зняти тиск із системи за допомогою динамічного середовища розробки та усунути велику частину раніше необхідних домовленостей у рамках команд підпроектів. Загальне невдоволення "окупованими" середовищами прийняття зараз залишилось у минулому.
Як недолік, ми повинні чітко вказати необхідну інфраструктуру. Чим більше систем прийому працює на кластері, тим більше обладнання нам потрібно. Кластер повинен фінансуватися відповідним чином. Крім того, є, звичайно, певна робота, пов’язана з налаштуванням та керуванням кластером та середовищами розробки, що працюють на ньому.