Яке призначення спеціальної машини для складання?

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

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

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

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

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

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

Сервер побудови пропонує набагато більше. Сервер збирання дозволяє проводити CI (безперервна інтеграція), це означає, що він автоматично будуватиметься при кожному натисканні на ваш VCS (наприклад, git), навіть може виконати тести одиниць, якщо у вас є, і дозволяє "розгортання в один клік". Сервери побудови можуть повідомляти вас за поштою, якщо збірки або тести не вдається. Вони пропонують історичні дані та тенденції щодо того, що сталося.

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

У світі Java одним з найбільш використовуваних серверів побудови є Дженкінс. Дженкінс прекрасно працює і зі збірками C ++ (оскільки, здається, ви використовуєте ці дві мови). Дженкінс називає себе сервером автоматизації, оскільки він може виконувати всілякі завдання, які не повинні бути пов'язані з програмуванням та побудовою.

Окрім відповіді Траубенфукса, ви натякали на ще одну причину побудови машини у своєму запитанні.

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

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

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

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

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

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

• По-перше, налаштуйте віддалений доступ до сервера збірки! Якщо ви будуєте вручну, ввівши команду "make", це означає, що вам більше не потрібно ходити в інший офіс, щоб набрати "make", ви можете просто SSH на сервер збірки та набрати "make". Якщо ви ще не використовуєте марку або подібну систему збирання, використовуйте таку систему складання.
• По-друге, встановіть середовище безперервної інтеграції, яке автоматично витягує останні зміни з системи контролю версій (у вас є система управління версіями, правда? Якщо ні, то це буде додатковим кроком) та будує їх. Рекомендую Дженкінс. Налаштуйте Дженкінс також для запуску тестів на одиниці та інтеграції на рівні системи (у вас є обидва, так? Якщо ні, створіть їх, починаючи з одиничних тестів, а потім закінчуючи тестами інтеграції на системному рівні).
• По-третє, якщо ви вважаєте, що обмінюватися тією ж машиною з іншими командами проблематично (наприклад, якщо у вас різні думки щодо того, якою операційною системою та якою версією та біт-версією ви користуєтесь), подумайте про використання віртуалізації. Хороший сервер сьогодні може запускати величезну кількість віртуальних машин. Можливо, ви могли б налаштувати собі 32-бітну і 64-бітну машини, щоб ви знали, що збірка працює на обох архітектурах.
• Нарешті, це може не бути необхідним: якщо ви абсолютно повинні мати спеціальну машину, наприклад, якщо продуктивність вашої програми має велике значення, а інші збірки / тестові запуски одночасно впливають на ваші результати занадто сильно, встановіть спеціальний сервер для апаратних засобів, ніж тільки ти використовуєш. Однак на останніх серверах, які можуть налічувати до 40 віртуальних ядер CPU або навіть більше, досить просто створити кілька віртуальних машин, які не мають доступу до одних і тих же ядер CPU.

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

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

Ви кажете, що так це погано.

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

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

Ви все ще виконуєте збірку вручну, і це не добре.

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

На додаток до інших відповідних відповідей, це також здається, що ви збираєте свої збірки безпосередньо на відповідній машині.

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

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

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

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