Який сенс "побудувати сервер"? [зачинено]

Я не працював у дуже великих організаціях і ніколи не працював у компанії, яка мала "Build Server".

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

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

Хтось, будь ласка, просвітліть мене: яка мета сервера складання?

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

Жоель Спольський з цього приводу.

Сервери побудови важливі з кількох причин.

• Вони ізолюють навколишнє середовище Місцевий розробник Code Monkey каже: "Це компілюється на моїй машині", коли він не збирається на вашій. Це може означати, що реєстрація не синхронізована або може означати відсутність залежної бібліотеки. Чорт пекла не так вже й поганий, як .dll пекло; в будь-якому випадку, використання сервера збірки - це дешева страховка, що ваші збірки не будуть таємниче виходити з ладу або пакувати неправильні бібліотеки помилково.

• Вони зосереджують завдання, пов’язані з побудовами. Сюди входить оновлення тегу збірки, створення будь-якої дистрибутивної упаковки, запуск автоматизованих тестів, створення та розповсюдження звітів про збірку. Автоматизація - це ключ.

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

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

Чому розробники не будують проект на своїх локальних машинах чи вони?
Тому що зі складним програмним забезпеченням, дивовижно багато речей може піти не так, коли просто "складати". проблеми, з якими я справді стикався:

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

У нас спостерігається дивовижне підвищення стабільності, оскільки всі публічні випуски починаються з управління з джерела на порожню папку. Раніше було багато "кумедних проблем", які "пішли, коли Джо дав мені нову DLL".

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

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

Це я просто не працював над досить великими проектами?

Розмір, безумовно, є одним із факторів, але не єдиним.

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

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

Щоб додати те, що вже було сказано:

Колишній колега працював у команді Microsoft Office, і мені сказали, що складання інколи займало 9 годин. Це було б гарно зробити це на ВАШІй машині, чи не так?

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

Я погоджуюся з відповідями на даний момент щодо стабільності, простежуваності та відтворюваності. (Багато 'іти, правда?). ТОЛЬКО колись працював у великих компаніях (охорона здоров’я, фінанси) з МНОГО серверами побудови, я додам, що мова йде також про безпеку. Коли-небудь бачили фільм Office Space? Якщо незадоволений розробник будує банківську програму на своїй локальній машині, і ніхто більше не дивиться на неї або не тестує її ... БУМ. Супермен III.

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

Одне використання - це імітувати типову конфігурацію кінцевого користувача. Продукт може працювати на вашому комп’ютері зі всіма створеними вами інструментами розробки та бібліотеками, але, швидше за все, кінцевий користувач не буде мати таку ж конфігурацію, як ви. З цього питання інші розробники не матимуть такої ж настройки, як і ви. Якщо у вас є код з твердим кодом десь у вашому коді, він, ймовірно, буде працювати на вашій машині, але коли Dev El O'per намагатиметься створити той самий код, він не працюватиме.

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

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

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

Ми використовуємо один, щоб ми знали, що у виробничих / тестових полях встановлені ті самі бібліотеки та версії цих бібліотек, що і на сервері збірки.

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

Ви праві, що розробники могли будувати на власних машинах.

Але це деякі речі, які купує нам наш сервер побудови, і ми навряд чи складні виробники:

• Проблеми з контролем версій (деякі згадані у попередніх відповідях)
• Ефективність. Devs не повинні зупинятися, щоб робити будівлі локально. Вони можуть розпочати це на сервері та перейти до наступного завдання. Якщо складання великі, то це ще більше часу, коли машина розробника не зайнята. Для тих, хто здійснює постійну інтеграцію та автоматизоване тестування, ще краще.
• Централізація. У нашій машині побудови є сценарії, які створюють збірку, поширюють її в середовищі UAT і навіть на стадії виробництва. Утримуючи їх в одному місці, зменшуються проблеми з синхронізацією.
• Безпека. Тут ми не робимо особливих особливостей, але я впевнений, що sysadmin може зробити так, що до інструментів міграції виробництва можна отримати доступ лише на сервері збирання певними уповноваженими особами.

Можливо, я єдиний ...

Я думаю, всі згодні з тим, що треба

• використовувати файлове сховище
• робити збірки з сховища (і в чистому середовищі)
• використовуйте нескінченний сервер тестування (наприклад, круїз-контроль), щоб побачити, чи щось порушено після ваших "виправлень"

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

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

Тож, можливо, "сервер побудови" - це просто помилка, а насправді це "безперервний тестовий сервер". Інакше це звучить досить марно.

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

Крім того, пам’ятайте, що мови низького рівня займають набагато більше часу, ніж мови високого рівня. Неважко подумати: "Ну дивіться, мій проект .Net збирається за пару секунд! У чому полягає велика справа?" Тим часом назад мені довелося возитися з деяким кодом С, і я забув, скільки часу потрібно на компіляцію.

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

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