Випустіть побудову проти нічного побудови

Типовим рішенням є складання CI (Безперервна інтеграція) на сервері збірки: воно проаналізує вихідний код, зробить збірку (налагодження) та запустить тести, виміряє покриття тесту тощо

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

Тепер питання:

• Чи краще мати третю окрему "Версію версії" як версію версії?
• Або "Nightly build" у режимі випуску і використовувати його як випуск?

Що ви використовуєте у своїй компанії?

(Збірка випуску також повинна додати якийсь тег до контролю джерела потенційної версії продукту.)

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

Різниця між випуском та нічним складанням:

• нічна збірка запускається автоматично, ну щовечора, тоді як збірка версій повинна виконуватися вручну в певні моменти часу
• release build має в ідеалі тегу / розгалуження вихідного коду та, можливо, розгорнути артефакт збірки в центральному репо-рене (наприклад, при використанні Maven)

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

Добре, я хотів би, щоб збірка версії була максимально наближеною до нічного! Ідеально точно так само, але з тегом.

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

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

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

Одне, що я хочу зробити, це перевести нічну збірку в режим випуску, а не в режим налагодження. З такими рамками ведення журналів, як log4net замінює System.Diagnostics.Debug, основними відмінностями між режимами Release і Debug є тривалість життя об'єктів та оптимізація коду.

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

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