З минулого досвіду роботи з кодовою базою Big Ball Of Mud, яка розвивалася природно протягом багатьох років від рук багатьох непідконтрольних молодшим розробникам, я хотів би зазначити, що відбувається, коли ти не практикуєш CI з тими розробниками.
Редагування / оновлення : Відповідно до коментаря RubberDuck; ця відповідь передбачає, що ваша мета об’єднання для інтеграції - це галузь розвитку, а не галузь оцінки або випуску.
- Очевидно, що потрібно мати набагато більше контролю над кодом для випуску та живого розгортання; якщо немає окремої галузі виробництва, тоді варто розглянути зміну вашої стратегії розгалуження / злиття, щоб запустити головну галузь розвитку (яка використовується для тестування інтеграції і ніколи для випуску) поряд з гілкою основного випуску. Це зберігає всі переваги CI і часті злиття, не ризикуючи порушити виробничий код.
1. Молодші розробники рідше спілкуються зі своїми колегами або керівником
Постійна інтеграція - це не просто питання злиття коду, це момент часу, коли розробник змушений взаємодіяти з іншими зацікавленими сторонами.
Комунікація важлива, і не бажаючи надмірно узагальнювати, вона, як правило, є засвоєною майстерністю, яка надходить природним чином для недосвідчених розробників, ніж для тих, хто звик працювати в командному середовищі.
Якщо ви дозволите молодшим розробникам сидіти у своєму кабінеті та тинятись за кодом тижнями, не вимагаючи частих звітів / оглядів, вони, швидше за все, уникають спілкування взагалі.
2. Код, який вони виробляють, швидше за все, потребуватиме більш жорсткого перегляду
Ви коли-небудь переглядали щось таке, що було так погано, що ви хотіли, щоб ви забрали його раніше і заважали йому коли-небудь писати? Це трапляється багато.
Ви не можете запобігти написанню поганого коду, але ви можете обмежити витрачений час. Якщо ви берете на себе часті огляди та злиття, то ви мінімізуєте сферу використання витраченого часу.
Найгірший сценарій полягає в тому, що ви можете залишити молодшого розробника в спокої на кілька тижнів на власному мініатюрному проекті, і коли вони, нарешті, готові до перегляду коду, просто не вистачає часу на те, щоб кинути весь безлад геть і почніть знову з нуля.
Багато проектів стають великою кулькою грязі просто тому, що було написано ціле навантаження поганого коду, коли ніхто не звертав уваги, поки не пізно.
3. Ви повинні бути менш впевнені, що молодший розробник або інший новий член команди зрозумів вимоги
Іноді розробник може створити ідеальне рішення для неправильної проблеми; це сумно, оскільки зазвичай зводиться до простих непорозумінь, яких було б так просто уникнути, якби раніше хтось ставив правильні запитання.
Знову ж таки, це проблема, яка швидше зачіпає недосвідчених розробників, які швидше сприймають «погані» вимоги за номіналом, а не підштовхують і ставлять під сумнів розумність вимоги.
4. Вони, ймовірно, менш знайомі як із загальними моделями, з архітектурою існуючого коду, так і з відомими інструментами та рішеннями
Іноді розробник витрачає цілий набір часу, щоб заново винайти колесо просто тому, що вони не знали, що кращого рішення навіть існує. Або вони можуть витратити дні, намагаючись забити квадратний кілочок у круглий отвір, не розуміючи, що вони роблять не так.
Знову-таки, подібні речі, швидше за все, трапляються у недосвідчених розробників, і найкращий спосіб вирішити цю проблему - забезпечити регулярні огляди.
5. Тривалі періоди між кодовими комісіями / злиттями ускладнюють ідентифікацію та виправлення дефектів
Коли помилка з'являється відразу після багатотижневих змін коду, об'єднаних у головну гілку, виклик визначення того, які зміни, можливо, спричинили помилку, ускладнюються.
Очевидно, ваша загальна стратегія розгалуження також грає тут; в ідеалі всі ваші розробники працюватимуть або у власних гілках, або в галузях функцій (або в обох), і ніколи не працюватимуть безпосередньо від головного / магістрального каналу.
Я бачив ситуації, коли цілі команди одночасно працюють безпосередньо в майстер / багажник, і це жахливе середовище для CI, але, на щастя, рішення відведення всіх від майстра / ствола, як правило, забезпечує достатню стабільність для індивідуальної роботи предмети / квитки / тощо.
Завжди має бути "добре", щоб будь-який розробник перервав гілку master / trunk, розуміючи, що злиття має відбуватися на регулярній основі, що зламування змін та дефектів слід ідентифікувати швидше, а отже, і вирішуватися швидше. Найгірші дефекти, як правило, є тими, які залишаються невиявленими протягом місяців або навіть років.
Підводячи підсумок; Основними перевагами безперервної інтеграції / безперервного розгортання є:
- Поліпшується спілкування між вашою командою
- Якість коду, як правило, підтримується на більш високому рівні
- Вимоги рідше можуть бути пропущені або неправильно витлумачені
- Проблеми з архітектурою та дизайном повинні бути виявлені швидше,
- Дефекти частіше виявляються та фіксуються на більш ранній стадії
Тож якщо ви не практикуєте CI зі своїми молодшими розробниками, ви приймаєте багато суттєвих зайвих ризиків, оскільки це члени вашої команди, які потребують цього більше, ніж решта.
it is more scary to wait a week to deploy all micro services at once to make sure that everything works together, than to strictly enforce api versioning, write lots of automatic tests (...), and auto deploy to production as soon as your commit passes as tests on stage- на цій думці;) IMHO набагато складніше забезпечити успіх при незалежному розгортанні сервісу, ніж при монолітному підході: softwareengineering.stackexchange.com/a/342346/187812 . І з справжнім CI (без функцій / інтеграційних гілок) вам не доведеться чекати тиждень.