Як зберегти багажник стабільним, коли тести займають тривалий час?

У нас є три набори тестових наборів:

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

У нас також є купа коротших тестових наборів, але я тут не зосереджуюсь на них.

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

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

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

І чи важливо, чи це централізована система управління джерелами, наприклад SVN, чи така розподілена, як git?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Невдалі середні тести: чи правда, що більшість часу одні й ті ж тести виходять з ладу?

Якщо є збій, чи завжди є однакові пов'язані тести, які не спрацьовують?

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

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

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

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

Ось що я пропоную:

1) Зробіть тести максимально атомістичними та максимально використайте навколишнє середовище.

2) Отримайте тестову ферму, щоб запустити їх. Якщо замість 8 великих модулів у вас закінчується 50, ви можете розкрутити купу екземплярів Amazon EC2 і запустити весь набір паралельно. Я впевнений, що це коштуватиме трохи грошей, але це заощадить величезну кількість часу для розробника.

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

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

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

Або ви можете бути абсурдно спрощеним і мати сценарій, який перераховує прохідні коміти в текстовому файлі (який може бути, а може і не контролюватися версією).

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