Динамични среди за разработка - какво е това
Местоположение: Начало »От практика» Динамични среди за разработка - какво е това?
В много от нашите проекти е обичайно да работим с няколко служители по няколко разработки едновременно. Ето защо често се случва две или повече задачи да бъдат разработени паралелно, но тествани или одобрени независимо една от друга. Ще ви разкажем защо решихме да използваме динамични среди за разработка, за да решим този проблем:
Как сме работили досега: Централни системи за приемане
По принцип ние създаваме отделен клон в Git за всяка задача, което означава, че паралелното тестване и одобрение не е проблем. За много проекти обаче имаме само една централна система за приемане. Тогава само един клон след друг може да се играе на тази система за приемане. Ако например приемането на разработка се забави поради отсъствието на служител или отговорното лице за контакт при клиента, засега се блокират всички по-нататъшни разработки и целият проект спира. Това не само води до забавяне на цялостния проект, но също така създава недоволство сред нашите служители.
За да можем да играем няколко клона едновременно в бъдеще, бяха необходими няколко системи за приемане. За тази цел вече разработихме концепция за динамични среди за разработка на TYPO3Camp Rhein-Ruhr 2017.
Как работят динамичните среди за разработка?
Въз основа на Docker и Kubernetes първоначално създадохме собствен клъстер за Docker контейнери.
Gitlab CI поема контрола върху динамичните среди за разработка. С всяко натискане на клон, работа в тръбопровода Gitlab CI създава нова версия на образ на Docker. Изображението за Docker е създадено специално за клона и включва, наред с други неща, всички артефакти и самия проект.
След това се стартира или актуализира среда за разработка с помощта на команда Slack или директно чрез Gitlab CI. Ако изтрием клона, тръбопроводът спира в Gitlab CI. Преди конвейерът да спре, заданието спира и изтрива средата за разработка.
Предимства и недостатъци на динамичните среди за развитие
Най-голямото предимство е ясно, че имаме собствена система за одобрение на всяка задача в даден проект. Това означава, че тестването и приемането на паралелни задачи вече не е проблем. Мениджърите на проекти и разработчиците не трябва да отделят повече време за игра и тестване на задача. Особено при клиентски проекти, при които много разработки и подпроекти често се изпълняват едновременно, успяхме да премахнем натиска от системата чрез динамичните среди за разработка и да премахнем голяма част от необходимите преди това споразумения в рамките на екипите за подпроекти. Общото недоволство от „заетите“ среди за приемане вече е в миналото.
Като недостатък трябва ясно да посочим необходимата инфраструктура. Колкото повече системи за приемане работят на клъстера, толкова повече хардуер се нуждаем. Клъстерът трябва да бъде финансиран по съответния начин. Освен това, разбира се, има известно количество работа, свързана с конфигурирането и управлението на клъстера и средите за разработка, работещи върху него.