Чи побудують суперечки та стабільний розвиток протиріччя?

Я є частиною групи розвитку з 5 командами, загалом близько 40 розробників. Ми дотримуємось методології Scrum, з 3-тижневими спринтами. У нас є безперервна установка інтеграції (Дженкінс), трубопровід якого займає кілька годин (за рахунок широких автоматизованих тестів). В основному процес розробки працює добре.

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

• Кожна комісія перевіряється на основі базового набору тестів. Після перевірки зміна буде натиснуто на головний після перегляду коду (Gerrit)
• Основні одиничні тести проводяться кожні 30 хвилин, тривалістю менше 10 хв
• Інтеграційні тести працюють кожні 2 год, тривалість 1 год
• UI- / веб-тести працюють на успішних тестах інтеграції, тривалістю декілька годин

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

Отже, ми хочемо:

1. Наші команди розробників розробляють та здійснюють зміни під час спринту безперешкодно
2. Якщо процес збірки не вдасться відмовитись від способу збирання, результати подальшого збирання мають мало значення
3. Наш процес збирання, щоб своєчасно надавати якісний зворотній зв’язок розробникам

З огляду на (2), пункти (1) та (3), здається, суперечать один одному. Хтось має добру практику, як з цим боротися?

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

Спасибі, Саймоне

По-перше, кілька основних принципів: - Основні зміни завжди повинні бути у вікні функції у вашому VCS - гілки функцій повинні пройти всі тести, перш ніж об'єднатись у магістраль. Додано - Коміти повинні завжди створюватися . Порушена збірка вимагає негайних дій з боку виконавця та / або іншої команди. - Невдалий тест повинен відміняти решту тестів, лише якщо це критичний тест.

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

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

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

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

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

Здається, ваша проблема полягає в тому, що для запуску тестів потрібно занадто багато часу. На щастя, закон Мура запропонував нам вирішення цієї проблеми. Сьогодні серверні процесори високого класу можуть легко мати понад 10 ядер (і понад 10 HyperThreads). В одному комп’ютері може бути кілька таких процесорів.

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

Отже, кілька годин перетворяться на 10-30 хвилин.

Ви не сказали, скільки часу займає збірка, але стандартні засоби збирання, такі як make, дозволяють паралелізувати також збірку. Якщо паралельно встановити свої тести на одиницю, а типовий комп'ютер-розробник має 4 ядра та 4 HyperThreads, менше 10 хвилин тестування одиниць перетвориться на менш ніж 2 хвилини. Тож, можливо, ви могли б застосувати політику, згідно з якою кожен повинен виконувати одиничні тести до здійснення?

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

Я не бачу ніякого зв’язку між Scrum та вашими проблемами. Проблеми справді можуть виникнути при будь-якому процесі розвитку.

Чи не можливо встановити більше установок Дженкінса і дозволити розробникам перевірити окремий екземпляр Дженкінса?

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

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

Точка (2) здається найбільш болючою точкою, тому я зупинюсь на цьому.

Можливо, час розбити проект на кілька модулів.

https://en.wikipedia.org/wiki/Dependency_inversion_principle

A. Модулі високого рівня не повинні залежати від модулів низького рівня. Обидва повинні залежати від абстракцій.

B. Абстракції не повинні залежати від деталей. Деталі повинні залежати від абстракцій.

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

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

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

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

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

• Код має одиничні тести
• Тестовий блок проходження як частина автоматизованої збірки
• Кодекс об'єднано в основний (і конфлікти вирішені)
• тощо.

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

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

Для TFVC це трохи складніше, тому що все відбувається на "дистанційному". Це означає, що розробники повинні завжди працювати з гілками, якщо це не швидко виправити. Тут застосовуються ті самі правила, що і у Git: неповне програмне забезпечення не виконується. Період. При правильному керуванні керуванням версіями "головне" завжди повинно бути звільненим. Якщо було зроблено зобов’язання, що борки є "головними", то ви не робите це правильно.