Як досягти плавного переходу від моделі організації «єдиний сховище VCS для всіх продуктів» до моделі «безліч малих сховищ VCS»?

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

У відповідях на це питання я хотів би побачити:

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

2. Відповідно до цього робочого визначення, розробіть план, який фактично виконує розкол. Можна зробити спрощене припущення, що база даних обробляється повністю автоматизованим sdlc, реалізуючи безперервну інтеграцію та безперервну доставку . Тобто, кожна гілка перевіряється автоматизованим тестовим набором, реалізованим у поточній кодовій базі даних, і кожне злиття з якоюсь "магічною" гілкою генерує артефакти продуктів , які тестуються та розгортаються. ( Артефактами товару є, наприклад, вихідні тарболи, документація, двійкові програмні пакети, зображення Docker , AMI, unikernel.)

3. Такий план є задовольняючим, якщо він пояснює, як обійти

Питання, порушені розколом

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

2. Як автоматизовані процедури розгортання стосуються раніше існуючого монолітного сховища та розділених сховищ?

3. Де зберігається код для самих процедур автоматизованого розгортання?

4. Де зберігаються інфраструктура , моніторинг та стратегії високої доступності ?

5. Як переконатися, що розробнику потрібна лише одна база коду за один раз (але можливе використання артефактів з інших баз кодів).

6. Як можна такий інструмент, як git-bisect

Маргінальна примітка: Переваги наявності продукту на сховищі VCS над моделлю репозиторію

Наявність декількох невеликих сховищ, що містять базу даних коду для конкретного продукту, має такі переваги перед підходом до "схожих сховищ":

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

2. Маючи складне сховище, важко переглядати історію проекту чи тягне, з невеликими сховищами ми швидше читаємо цю інформацію. (Це може бути специфічно для VCS, як git, де на відміну від svn, ми не можемо перевірити підрядки!)

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

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

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

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

7. Маючи кілька невеликих сховищ, легше мати декількох власників продуктів.

8. З декількома невеликими сховищами легше мати прості стандарти коду, що стосуються повного сховища, які можна автоматично перевірити.

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

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

Дизайн

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

Впевненість

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

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

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

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

Якщо такий код тесту взагалі відсутній, він спочатку записується.

Стратегія

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

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

Технічний борг

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

Реагрегація

Зрештою цього, ви все ще можете надати єдиний вид сховища сховища, в якому ви можете створити більше одного продукту. З будь-якої причини, тобто curr / next release, multibrand, клієнт будує. Такі засоби, як google repo, можуть допомогти в цьому випадку. Ніколи не використовував одного, але я знаю, що мені знадобиться один день.

Інтеграційне тестування

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

PS. це чернетка, моя англійська погана, і я виправлю це одного дня