Хто несе відповідальність за налаштування системи автоматизованих побудов?

Я керівник проекту в своїй компанії. Я працюю з кількома командами розробників, використовуючи стандартну, відому систему управління версіями, відому як CVS. Я хотів би бачити постійну інтеграцію та впроваджувати автоматизовані збірки, щоб запобігти проблемам з розривом збірки та поганим розгортанням, що прокрадається на виробничі сервери.

Я впевнений, що можу це налаштувати сам, але я не хочу цього робити сам з двох причин:

1. У мене немає часу на це. У мене є власні обов'язки, які стосуються маркетингу, спілкування з іншими зацікавленими сторонами з членами команди, які не є частиною розвитку, спілкування з клієнтами та планування проектів.

2. Найголовніше, що я керівник проекту. Моє призначення - забезпечити лідерство, а не мікроуправління командою розвитку .

Які речі я можу зробити, щоб знайти когось із команди розробників, який би пристрасно налаштувався на це? Чи є розробник потрібною людиною для цього завдання, вважаючи, що він потребує знання Java, Spring та Google App Engine? Які поради можна сприяти змінам, коли страх зміниться?

Я б спершу дослідив деякі можливості. Наприклад, Хадсон - досить популярний сервер безперервної інтеграції і надзвичайно гнучкий. Ви можете надіслати електронною поштою своїй команді розробників щось подібне:

Я хотів би запровадити інструмент безперервної інтеграції, щоб токсичні ревізії виявилися набагато швидшими, ніж пізніше. Я подивився на [Гудзон, Акме СНД, foo], і всі вони виглядають так, як працювали б. Враховуючи той факт, що ми використовуємо CVS з [переліком тут застережень], я шукаю рекомендації, і буду працювати з тим, що вирішить команда.

Дейв, будь ласка, візьми відповідальність за досягнення консенсусу та розпочавши це. Команда - будь ласка, введіть свій внесок у Дейв до кінця дня четверга, щоб ми могли перевірити це у п’ятницю.

Будь ласка, надішліть мені мої дані, коли ми щось встановимо.

Цей підхід має такі переваги:

• Ви делегуєте, а не демпінгуєте
• Люди знають, що ви провели деякі дослідження, якість речей, які ви вказуєте, допомагає визначити ваші очікування щодо якості застосованого інструменту
• Вам відомо [застереження], давайте не будемо зривати їх з обговореннями, якщо вони справді не є вимикачами для вирішення завдання.
• Ви дозволяєте трохи демократії. Звичайно, ви увійдете в систему, щоб побачити, що щось зламалося, але люди, яким доведеться мати справу з СНД, будуть саме ті, хто обрав платформу.

За моїм макетним сценарієм, він Daveбув обраний тому, що він має найменше на своїй тарілці і, ймовірно, не матиме проблем із налаштуванням нового сервера. Залежно від робочого навантаження, Daveможливо, вам доведеться бути саме ви. Це настільки суб'єктивно, що я просто згадую про це. Ти не завжди можеш сказати, not my job to do thatособливо якщо ти єдиний, хто на це встигає. Якщо всі вже тягнуться з часом, їхнє сприйняття вашої готовності допомогти стає важливішим. Оцінка, це вміння, яке ви розвиваєте з часом.

У будь-якому випадку у вас буде або сервер СНД до п’ятниці, або деталі, чому це просто неможливо без додаткового набору рук.

Я бачу це шляхом трьох можливих способів:

1. Нехай хтось із команди розробників придумає швидку оцінку можливих інструментів і дозвольте йому швидко щось збити. Якщо ваші індивідуальні проекти мають належні сценарії збірки (тобто ви можете будувати проекти за межами IDE), тоді слід досить швидко підключити їх до ІС.

2. Ставтеся до інфраструктури побудови як до внутрішнього проекту в межах своєї команди та керуйте нею як такою. Трохи більше, ніж перший пункт, але якщо зробити все правильно, ви отримаєте кращу систему. Також розповсюдження знань по команді зменшить ризик переспеціалізації, згаданого нижче. Ви також отримуєте переваги експертної оцінки. Однак деякі програмісти можуть сприймати це завдання як принизливе і як таке не можуть витрачати на нього стільки, скільки слід.

3. Найміть розробника як майстра побудови та запропонуйте йому налаштувати всі інструменти. Потім продовжуйте використовувати його для вдосконалення системи, додавання показників, автоматизованої генерації документів, автоматизованого тестування тощо. Це дорожче, але якщо зробити все правильно, інвестиції в цю людину окупляться дуже швидко, підвищуючи ефективність роботи вашої команди розробників. Ця людина має добре володіти мовами та рамками, якими користується ваша команда, і мати бажання склеювати їх у системі. З іншого боку (з коментарів), це може не входити до вашого бюджету, і створення спеціалізованої посади може призвести до розроблення документально вирішеного рішення, яке може ускладнити переходи.

Це сказало, перш ніж починати що-небудь, будьте впевнені, що ви насправді хочете від цього. У вашому запитанні відсутні трохи деталей, щоб направити вас у правильному технічному напрямку. Вам потрібно знати, яких вигод ви хочете досягти у використанні таких інструментів, вам потрібно загальне бачення потрібної системи. Можна створити довгий шлях у створенні середовища, яке пов'язує все це, але без генерального плану, який можна створити проти вас, ви також можете запускати кола та робити речі складнішими, ніж ті, які вони є.

Менеджер, який я колись казав, що інструменти хороші, але без процесу вони марні. Я б тільки хотів, щоб він продовжував діяти над тим, що він сказав, коли прийшов час поставити їх на місце ...

Отже, якщо ви вирішили наймати когось, є певні переваги в тому, щоб отримати програміста, а не когось із більш італійським досвідом. Основний момент полягає в тому, що ця людина може витратити певний час та енергію на створення коду клею та плагінів, які інтегруватимуть різні системи разом у цілісну систему.

Сподіваюся, що це допомогло

Якщо у вас є керівна роль, ваша робота - визначити відсутні компоненти / практики та вашу відповідальність за правильне виконання. Завдання реалізації може бути делеговане чи ні, але в кінцевому рахунку це відповідальність лідерів.

Запорукою прийняття є розуміння або принаймні надання користі сумніву. Ви можете поговорити про те, що ви хочете зробити, і призвести до витрат і користі. Якщо дискусія не порозуміє вас, ви можете розраховувати на їх довіру до своїх рішень, але лише якщо ви створили такий репортаж.

Якщо ваша делегування досягає обмежень у часі, підсуміть це під час протистояння чи зустрічі команди та попросіть добровольця. Якщо ніхто не йде, просто призначте його, як і будь-який інший твір.

оновлення:

Всередині компанії існує організаційна структура. Лідерська роль несе відповідальність за ресурси на цьому рівні. Вони також несуть відповідальність за вказівку та вирішення будь-яких проблем. Можливо, їм знадобляться додаткові ресурси та / або пропозиція, коли ви піднімаєтесь по ланцюгу. Якщо ви можете вирішити це питання, у вас є можливість реалізувати рішення самостійно або делегувати. Це може і має залучати людей, на які це вплине безпосередньо, в ідеалі у співпраці з ними.

Я не можу сказати, що рівень директора та вище посади ніколи не повинні бути безпосередньо відповідальними за конкретну людину чи групу в компанії. Це дійсно залежить від організаційної структури компаній. Я працював на стартапах, де ЦТО відповідав безпосередньо за розробників та тестерів. У більш традиційному масштабному керівництві компанії на цьому рівні не було б необхідної видимості чи знайомства, необхідних для прийняття відповідних рішень на цих нижчих рівнях.

Я здебільшого розробник, і налаштовую це, коли можу (а саме тоді, коли мені це прямо не заборонено). Як правило, оскільки місцями, в яких я працюю, є магазини .NET, я вибираю CruiseControl.NET, оскільки він є відкритим кодом, працює з більшістю основних систем управління джерелами і порівняно простий у користуванні. Я завжди хотів створити Ambient Orb в якості одного з результатів, але це, як правило, поза моїм контролем.

Виконайте це на зустрічі, щоб спочатку побачити, чи є у когось бажання це зробити, доки це не вплине на проекти, над якими зараз працюють.

У моєму теперішньому місці (одному з національних лабораторій) у нас це створено просто для того, щоб будувати послідовно побудови, щоб люди, які хочуть бачити, що ми робимо, змогли отримати версію, яку можна виконати в будь-який час . Вони не хочуть тестування одиниць (враження керівника проекту полягає в тому, що зусилля, які ми доклали до тестування підрозділів, можна було б докласти до перенесення проекту в .NET).

У моєму попередньому місці намір полягав у тому, щоб робити складання стандартними та послідовними у всіх продуктах. Занадто багато продуктів можна було побудувати лише на одному спеціальному комп'ютері (у випадку з одним продуктом, із залученням сторонніх керуючих з агресивним DRM, які давно не вийшли з ладу, нам довелося тримати одну машину в живих близько 5 років після виходу розробника. адже його було єдиним, хто міг побудувати цей замінений зараз комерційний товарний товар). Крім того, встановлення могла зробити лише одна людина, яка була ранковою людиною - тому, якщо вам потрібна була побудова приблизно через 15:00, ви зачекали до наступного дня.

Чи є розробник потрібною людиною для цього завдання, вважаючи, що він потребує знання Java, Spring та Google App Engine?

Це залежить. Якщо у вас є якась людина з якості, яка пристойно ставиться до сценаріїв, попросіть спочатку, перш ніж призначити їх.

Встановити його для початку - не складне завдання. Налаштування не повинно зайняти більше декількох днів (переважно в корпоративному середовищі, клопоти отримують обліковий запис для роботи з усіма необхідними дозволами) та розпочинають працювати.

Спробуйте налаштувати його в іншому напрямку - коли є проблеми у виробничому середовищі, наділіть команду розробників, щоб виправити її та швидко виправити. Тоді введіть ідею простої нічної збірки, яка компілюється з останнього коду, штамп версії тощо. Якщо це не вдалося побудувати, вона не буде просуватися.

Я думаю, що сценарій збирання повинен належати розробці. Коли вони змінюють залежності або вносять зміни, вони найкраще знають, як оновити сценарії. І скажіть їм, що якщо керівництво проектом володіє ним, ви просто зателефонуєте їм на зустріч, коли будь-яка проблема.

Ви можете просто сказати на наступному засіданні: "Добре, я думаю, що ми повинні це зробити через те, хто може це реалізувати" Я даю вам краще, ніж навіть шанси, хтось скаже "Звичайно, я це зроблю". тоді вам не доведеться боротися з цим.