Стратегії просування залежностей: розкладений або оркестрований?

У нас є багато додатків та веб-служб (деякі суспільні продукти, деякі внутрішні та частина приватного «задніх місць»), які взаємозалежні один від одного. Кожен з цих компонентів має 4 середовища (кластери серверів / вузлів, що обслуговують певні цілі):

• Невиробнича
  • DEV- інтегроване середовище розробки, де CI будує поштовх змін; корисно для інженерів для усунення помилок, які важко знайти, які не відтворюються локально
  • QA - Ізольоване середовище забезпечення якості / тестування
  • DEMO - Стабільне середовище UAT для зацікавлених сторін бізнесу
• Виробництво
  • LIVE - Наше живе / виробниче середовище

Просування коду йде: LOCAL(машина розробника) => DEV=> QA=> DEMO=> LIVE.

Скажімо, у нас є додаток під назвою, myappяке підтримується RESTful веб-сервісом myws, який називається , який сам підтримується БД mydb.

В даний час у нас є те, що я б назвав " оркестрованим " просуванням серед цих залежностей: myapp-devбали, до myws-devяких користується mydb-dev. Аналогічно myapp-qaвказує на myws-qaвикористання mydb-qa. Те саме для DEMOі LIVE.

Проблема в цьому полягає в тому, що щоразу, коли я вношу зміни, скажімо myapp, це вимагає від мене внесення змін mywsі mydbдо них. Але оскільки кожне DEVсередовище вказує на середовища його залежностей DEV, це означає, що я повинен запланувати та розгорнути ці зміни все одночасно. Крім того, якщо одна збірка стає нестабільною / зламаною, вона часто збиває інші компоненти за течією; наприклад, якщо розробник щось ламає при зміні mydb-dev, кластери myws-devі, myapp-devяк правило, також стають нестабільними.

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

• Залежно видобутку нафти і газу залежить від DEMOсередовища для їх вниз по течії залежностей, для всіх їх невиробничих середовищ ( DEV, QAі DEMO); і
• Залежності вище за течією залежать від LIVEнавколишнього середовища, залежно від їх виробничого середовища

Використовуючи цю конвенцію, можна myapp-devбуло б вказувати на те myws-demo, що було б корисно mydb-demo. Так myapp-qaсамо вказували б myws-demoі на mydb-demo.

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

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

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

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

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

"Стратегія промоції промоції" здається, що це тільки погіршить. Якщо myapp v2, myws v2 та mydb v2 є лише на DEV, а myapp v2 покладається на mydb v2, щоб він не вийшов з ладу, тоді, коли я спробую запустити myapp v2 на DEV, я потрапляю на mydb v1 DEMO і він руйнується. По суті, ви будете змушені або постійно перекривати силоси, або розгортати mydb v2 до повного продукту, перш ніж ви навіть можете почати працювати над myapp v2. Що ще важливіше, ви ніколи не будете тестувати mydb v2 на DEV, тож якщо він зламаний, ви навіть не дізнаєтесь, поки він не зламається на DEMO, і тоді ви повернетесь до квадратного.

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

Крім того, якщо одна збірка стає нестабільною / зламаною, вона часто збиває інші компоненти за течією; наприклад, якщо розробник щось порушує при зміні mydb-dev, кластери myws-dev і myapp-dev зазвичай також стають нестабільними.

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

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

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