Фон

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

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

Що я шукаю

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

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

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

// TODO by v55: Create migration to move constraints to new column, remove references to old column in app
// TODO by v56: Create migration to drop old column

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

Додаткові думки

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

EDIT: Я просто думав про іншу ситуацію, коли це може бути корисним. Якщо ви використовуєте Feature Toggles, щоб увімкнути частини програми, коли вони будуть готові, ви повинні бути обережними, щоб очистити їх, інакше у вас може виникнути проблема Toggle Debt . Коментарі з термінами можуть стати гарним способом пам’ятати про це.

Це питання справді два питання в одному.

Тодо коментує

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

Що з цим робити

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

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

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

Зміни бази даних

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

Процес після розгортання

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

1. сценарії баз даних
2. веб-додатки
3. Сценарії бази даних postapp
4. сценарії баз даних вікна обслуговування

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

Postapp був зарезервований для незвичайних випадків, коли нам потрібно було внести несумісні зміни схеми. У цих випадках preapp внесе достатньо змін, щоб зробити новий код програми сумісним (можливо, створити тимчасовий вигляд сумісності), а postapp очистить будь-які такі тимчасові артефакти.

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

Застосовуйте часто

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

Не використовуйте TODO. У вас уже є список TODO у вашому проекті. Це називається трекер випуску.

Я думаю, що справжня проблема полягає в цьому реченні:

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

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

Якщо ваше керівництво надмірно затримує останню частину завдання, у вас є два варіанти:

1. поговоріть зі своїм керівництвом, чому це погана ідея.

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

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

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

// TODO by v55: Створіть міграцію для переміщення обмежень до нового стовпця, видаліть посилання на старий стовпець у додатку // TODO by v56: Створіть міграцію, щоб скинути старий стовпець

grep for //TODO by v55коли настав час розгортати v55. Розгортання збирання виконує сценарій, який робить це як тест інтеграції.

Ви можете прив'язати 55 до відстеження версій або просто підкажете про це.

Це стає цікавим, якщо ви хочете перевірити // TODO by v54, коли робите 55. Скоріше шукайте базу коду 55 разів, просто шукайте // TODO by. Потім відфільтруйте цей результат від 1 до 55. Тепер 56 не призведе до помилки.

Ви можете подумати, "о, нам це не потрібно. Ми будемо це виправляти кожен раз, поки у нас буде чек". Ні. Ні, ви не будете.

У нас в команді була дуже схожа проблема. Для вирішення цього питання ми написали перевірку статичного аналізу, яка обробляє ці TODO, перевіривши проблему JIRA або Git Issue, на яку вони посилаються. Наша збірка не вдається, коли вказаний випуск проходить повз стовпця "У розробці".

Тому ми можемо комфортно мати TODO, не турбуючись про те, що вони забудуть.

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

Інструмент називається Westie, а приклад перевірки проблем Jira - на README.md. Дивіться також GitIssueAnalyser.

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

Не ToDo. Зробіть це зараз.

TLDR: Напишіть (і протестуйте) свої сценарії БД зараз, не пізніше; просто кодуйте їх, щоб їх виконання залежало від версії БД.

Приклад

Для прикладу, давайте уявимо, що ви хочете змінити назву стовпця з SSNна TaxID, звичайна вимога, коли ви переходите на міжнародний рівень.

Щоб це сталося, можливо, у вас буде тимчасово і а, TaxIDі SSNстовпець. І підтримуючи обидві версії, у вас буде тригер для оновлення однієї з іншої. Але ви не хочете тримати цей тригер на невизначений час, тому пізніше, коли зворотна сумісність більше не потрібна, ви хочете, щоб цей тригер був видалений (і SSNстовпець опустився). Ми будемо кодувати все це наперед без необхідності елементів ToDo.

У нашому прикладі ми будемо розгортати збірку 102 (у якій є новий стовпець), зберігаючи сумісність із збіркою 101 (що не відповідає).

Ось етапи.

1. Налаштуйте таблицю версій

1. Додайте єдину таблицю Configurationз двома стовпцями Nameта Value.

2. Додайте рядок з Name"TargetVersion" і встановіть Valueверсію нової збірки для розгортання.

3. Додайте рядок із Name"CompatibleWith" і встановіть Valueмінімальний номер версії, з якою розгортання має бути сумісним.

Перевіряйте та оновлюйте ці рядки перед кожним розгортанням.

2. Змінення сценаріїв розгортання

1. Додайте скрипт, який створює новий стовпчик TaxID, поруч із ним SSN, і заповнює його зі SSNстовпця. Додайте цей код до Ifзаяви, яка перевіряє TargetVersion; якщо цільова версія занадто низька (тобто TaxIDще не потрібна), пропустіть.

   SELECT @TargetVersion = TargetVersion FROM Configuration
   IF @TargetVersion < '102' THEN RETURN
   ALTER TABLE Customer ADD COLUMN taxID VarChar(12) NOT NULL
   UPDATE Customer SET TaxID = SSN
   

2. Додайте скрипт, який створює тригер, який заповнюється TaxIDпід час вставки чи оновлення SSNта навпаки. Додайте цей код до Ifзаяви, яка перевіряє цільову версію та сумісну версію; пропустити, якщо TargetVersion занадто низький ( TaxIDне потрібен) або якщо версія CompatibleWith зависока ( SSNполе не потрібно).

   SELECT @TargetVersion  = TargetVersion,
          @CompatibleWith = CompatibleWith 
   FROM Configuration
   IF @TargetVersion  < '102' THEN RETURN
   IF @CompatibleWith > '101' THEN RETURN
   CREATE TRIGGER SSNAndTaxIDTrigger ON Customer etc.
   

3. Додати сценарій для видалення SSNстовпця. Докладіть до Ifзаяви, яка видаляє стовпець, лише якщо версія CompatibleWith досить висока ( SSNбільше не потрібна).

   SELECT @CompatibleWith = CompatibleWith FROM Configuration
   IF @CompatibleWith <= '101' THEN RETURN
   IF OBJECT_ID('SSNAndTaxIDTrigger') IS NOT NULL DROP TRIGGER SSNAndTaxIDTrigger
   IF EXISTS (SELECT * FROM syscolumns c JOIN sysobject o ON o.id = c.is WHERE o.Name = 'Custeomr' AND c.Name = 'SSN') BEGIN
       ALTER TABLE Customer DROP COLUMN SSN
   END
   

3. Тестування

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

4. У вашій книзі розгортання

Додайте крок інженеру для оновлення версії CompatibleWith та рядків TargetVersion. Якщо ви розгортаєтеся в Blue, встановіть для TargetVersion номер версії Blue, а для версії CompatibleWith - номер версії Green; поверніть їх назад, якщо ви розгортаєте Green.

Підводні камені

Добре, щоб ваші сценарії розгортання посилалися і покладалися на ті номери версій, які містяться в цій таблиці БД. НЕ код виконання.

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

Підсумок усього цього

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

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

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

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

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