Коли робити огляд коду під час постійної інтеграції?

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

Тож питання полягає в тому, коли ми робимо огляди коду?

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

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

ІМО, ви повинні переглянути код, перш ніж він буде опублікований на мейнлайн, щоб лише в основній лінії був код найвищої якості.

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

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

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

(Повне розкриття: я працював для SmartBear, виробників Code Collaborator, інструменту перегляду коду)

Налаштувати парне програмування?

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

Ось виписка автора безперервної доставки:

Jez Humble пише:

На даний момент я пишу повідомлення в блозі на цю тему. Коротка відповідь така:

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

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

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

Спасибі,

Jez.

оригінальне посилання: https://groups.google.com/forum/#!msg/continuousdelivery/LIJ1nva9Oas/y3sAaMtibGAJ

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

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

І для цього є дві речі: тести інтеграції та перевірка коду експертного коду. Інтеграційні тести допомагають бути впевненими, що новий код не порушує існуючий код. Що стосується огляду коду рівних, то ми робимо це в п’ятницю, це трохи полегшений час для цього :-) Кожен розробник призначений у галузь, над якою він не працює, потребує певного часу, щоб прочитати вимоги спершу нову функцію, а потім перевіряє, що зроблено. Найважливіша його робота - переконатися, що новий код працює так, як очікувалося, враховуючи вимоги, не порушує наші власні «правила» (використовуйте цей об’єкт для цього, а не той), його легко читати, і що він дозволяє легке розширення.

Таким чином, у нас є два огляди коду, один автоматичний і один "людський", і ми намагаємося уникати неперевіреного коду у відділенні HEAD. Зараз ... Це трапляється іноді з різних причин, ми далеко не ідеальні, але ми намагаємось підтримувати справедливий баланс між якістю та вартістю (час!)

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

Я думаю, що головна концепція, яка допоможе, - це концепція зони "постановки".

Так, ви не хочете перевіряти код, який порушено. Але ви також повинні часто перевіряти код. Це означає досконалість? ;) Ні. Просто використовуйте декілька областей та DVCS, як git.
Таким чином ви вносите зміни (локально) і здійснюєте їх часто під час тестування та розвитку, поки тести не пройдуть. Потім ви перейдете до місця постановки для перегляду коду.

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

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

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

Декупаж коду і безперервна інтеграція!

Чому ти їх поєднав?

Ми використовуємо git flow для своїх сховищ, і ми робимо свої огляди коду, коли мова йде про об'єднання в галузь розробки.

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

У нас також створено ІС для нашої розробки та освоєння галузей.

Я дуже-дуже-дуже думаю, що вам знадобиться DVCS (наприклад, mercurial, git), щоб це зробити природним шляхом. З CVCS вам знадобиться гілка і сподіваєтесь, що будь-якого бога у вас немає, пекло не зливається.

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

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

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

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

Найголовніше, що за допомогою DVCS ви все ще можете підтримувати централізований робочий процес, вам не потрібно мати ще один вигадливий робочий процес, якщо ви цього не хочете ... але за допомогою DVCS ви можете відокремити центральний сховище розробки від CI сервер і надати комусь повноваження пересилати зміни з dev repo на CI repo, коли сеанс перегляду коду зроблено .

PS: Кредит на зображення йде на git-scm.com

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

Залежно від шляху, який змінюються в процесі їх переміщення через систему, це може виявитися складним рішенням і може найкраще працювати при використанні таких інструментів, як Git або Mercurial Queues (застереження: я не використовував ні в гніві) але багато організацій роблять щось подібне.

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

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

• ^{З іншого боку, єдиний випадок, коли я був у проекті, який намагався "одружитися", перегляд коду перед C- кодом з CI виявився досить болісним. Добре, коли все пройшло на 100% гладко, все було нормально, але навіть нечасті перебої (наприклад, коли основні та резервні рецензенти були недоступні, скажімо, кілька годин) зробили помітний стрес. Я також помітив, що моральна команда дещо страждала - було занадто багато конфліктів.}

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

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

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

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