Нулев престой при внедряване и бази данни

Тази статия обяснява подробно как да разрешите проблеми със съвместимостта на базата данни при внедряване. Ще ви кажем какво може да се случи с вашите производствени приложения, ако се опитате да внедрите без предварителна подготовка. След това ще преминем през етапите на жизнения цикъл на приложението, които са необходими, за да има нулев престой (прибл. лента: по-нататък - нулев престой). Резултатът от нашите операции ще бъде прилагането на обратно несъвместимата промяна на базата данни по обратно съвместим начин.

Ако искате да разберете примерите за код от статията, можете да ги намерите на GitHub.

въведение

Разгръщане с нулево време на престой

Каква мистика разгръщане с нулево време на престой? Можете да кажете, че това е, когато вашето приложение е разгърнато по такъв начин, че можете успешно да въведете нова версия на приложението в производството, докато потребителят не забелязва липсата му. От гледна точка на потребителя и компанията, това е най-добрият възможен сценарий за внедряване, защото позволява въвеждането на нови функции и коригирането на грешки без прекъсване.

Как да постигнем това? Има няколко начина, ето един от тях:

• внедрите версия №1 на вашата услуга
• извършете миграция на база данни
• Разположете версия #2 на вашата услуга успоредно с версия #1
• веднага щом видите, че версия № 2 работи както трябва, премахнете версия № 1
• готов!

Лесно, нали? За съжаление не е толкова просто и ще го разгледаме по-подробно по-късно. Сега нека проверим друг доста често срещан процес на внедряване - синьо-зелено внедряване.

Чували ли сте някога синьо зелено разполагане? Cloud Foundry прави това изключително лесно. Просто погледнете тази статия, където описваме това по-подробно. За да обобщим накратко, нека ви напомним как да направите синьо-зелено внедряване:

• уверете се, че две копия на вашия производствен код („синьо“ и „зелено“) работят;
• насочи целия трафик към синята среда, т.е. така че производствените URL адреси да сочат там;
• внедрите и тествайте всички промени в приложението в зелена среда;
• превключете URL адресите от синя към зелена среда

Синьо-зеленото внедряване е подход, който ви позволява лесно да въвеждате нови функции, без да се притеснявате от прекъсване на производството. Това се дължи на факта, че дори ако нещо се случи, можете лесно да се върнете към предишната среда, като просто „натиснете превключвател“.

След като прочетете всичко по-горе, може да зададете въпроса: Какво общо има нулевият престой със синьо-зеленото внедряване?

Е, те имат доста общи неща, тъй като поддържането на две копия на една и съща среда изисква двойно усилие за поддържането им. Ето защо някои отбори твърдят Мартин Фаулър, следвайте вариант на този подход:

Друг вариант е да използвате една и съща база данни, създавайки синьо-зелени превключватели за уеб и домейн слоеве. При този подход базата данни често може да бъде проблем, особено когато трябва да промените нейната схема, за да поддържа нова версия на софтуера.

И тук стигаме до основния проблем в тази статия. база данни. Нека да погледнем отново тази фраза.

извършете миграция на база данни.

Сега трябва да си зададете въпроса - какво ще стане, ако промяната на базата данни не е обратно съвместима? Няма ли първата ми версия на приложението да се повреди? Всъщност точно това ще се случи...

Така че, дори въпреки огромните предимства на нулевия престой/синьо-зелено внедряване, компаниите са склонни да следват следния по-безопасен процес за внедряване на своите приложения:

• подготви пакет с нова версия на приложението
• затворете работещо приложение
• стартирайте скриптове за мигриране на базата данни
• внедряване и стартиране на нова версия на приложението

В тази статия ще опишем подробно как можете да работите с вашата база данни и код, за да се възползвате от внедряването без престой.

Проблеми с базата данни

Ако имате приложение без състояние, което не съхранява никакви данни в базата данни, можете веднага да получите нулево внедряване на престой. За съжаление повечето софтуери трябва да съхраняват данни някъде. Ето защо трябва да помислите два пъти, преди да направите каквито и да било промени във веригата. Преди да навлезем в подробности за това как да промените схемата, така че да е възможно внедряване без престой, нека първо се съсредоточим върху схемата за управление на версиите.

Схема за управление на версиите

В тази статия ще използваме Път за прелитане като инструмент за контрол на версиите (прибл. Превод: говорим за миграции на бази данни). Естествено, ние също ще напишем приложение Spring Boot, което има вградена поддръжка на Flyway и ще извърши миграция на схема, докато настройва контекста на приложението. Когато използвате Flyway, можете да съхранявате скриптове за миграция в папката на вашите проекти (по подразбиране в classpath:db/migration). Тук можете да видите пример за такива файлове за миграция

└── db
 └── migration
     ├── V1__init.sql
     ├── V2__Add_surname.sql
     ├── V3__Final_migration.sql
     └── V4__Remove_lastname.sql

В този пример виждаме 4 скрипта за миграция, които, ако не бъдат изпълнени преди това, ще бъдат изпълнени един след друг, когато приложението стартира. Нека да разгледаме един от файловете (V1__init.sql) като пример.

CREATE TABLE PERSON (
id BIGINT GENERATED BY DEFAULT AS IDENTITY,
first_name varchar(255) not null,
last_name varchar(255) not null
);

insert into PERSON (first_name, last_name) values ('Dave', 'Syer');

Всичко е напълно очевидно: можете да използвате SQL, за да определите как вашата база данни трябва да бъде модифицирана. За повече информация относно Spring Boot и Flyway вижте Spring Boot Docs.

Като използвате инструмент за контрол на източника с Spring Boot, получавате 2 големи предимства:

• разделяте промените в базата данни от промените в кода
• Миграцията на база данни се извършва заедно с внедряването на вашето приложение, т.е. вашият процес на внедряване е опростен

Отстраняване на проблеми с базата данни

В следващия раздел на статията ще се съсредоточим върху разглеждането на два подхода към промените в базата данни.

• обратна несъвместимост
• обратна съвместимост

Първият ще се счита за предупреждение, че не трябва да извършвате внедряване с нулев престой без предварителна подготовка... Вторият предлага решение за това как можете да извършите внедряване без престой и в същото време да поддържате обратна съвместимост.

Нашият проект, върху който ще работим, ще бъде просто приложение Spring Boot Flyway, което има Person с first_name и last_name в базата данни (прибл. превод: Person е маса и first_name и last_name - това са нивите в него). Искаме да преименуваме last_name в surname.

Предположения

Преди да навлезем в подробностите, има няколко предположения, които трябва да направим относно нашите приложения. Основният резултат, който искаме да постигнем, ще бъде доста прост процес.

Бележката. Бизнес ПРО-СЪВЕТ. Опростяването на процесите може да ви спести много пари за поддръжка (колкото повече хора работят за вашата компания, толкова повече пари можете да спестите)!

Няма нужда от връщане на базата данни

Това опростява процеса на внедряване (някои връщания назад към бази данни са почти невъзможни, като връщане към изтриване). Предпочитаме да връщаме само приложения. По този начин, дори ако имате различни бази данни (например SQL и NoSQL), вашият канал за внедряване ще изглежда по същия начин.

ВИНАГИ трябва да е възможно приложението да се върне една версия назад (не повече)

Връщане назад трябва да се извършва само когато е необходимо. Ако има грешка в текущата версия, която не се коригира лесно, трябва да можем да се върнем към най-новата работеща версия. Предполагаме, че тази последна работна версия е предишната. Поддържането на съвместимост на код и база данни за повече от едно внедряване би било изключително трудно и скъпо.

Бележката. За по-голяма четливост в тази статия ще променим основната версия на приложението.

Стъпка 1: Първоначално състояние

Версия на приложението: 1.0.0
DB версия: v1

Коментар

Това ще бъде първоначалното състояние на приложението.

Промени в базата данни

DB съдържа last_name.

CREATE TABLE PERSON (
id BIGINT GENERATED BY DEFAULT AS IDENTITY,
first_name varchar(255) not null,
last_name varchar(255) not null
);

insert into PERSON (first_name, last_name) values ('Dave', 'Syer');

Промени в кода

Приложението съхранява данни за лица в last_name:

/*
 * Copyright 2012-2016 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package sample.flyway;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Long id;
    private String firstName;
    private String lastName;

    public String getFirstName() {
        return this.firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return this.lastName;
    }

    public void setLastName(String lastname) {
        this.lastName = lastname;
    }

    @Override
    public String toString() {
        return "Person [firstName=" + this.firstName + ", lastName=" + this.lastName
                + "]";
    }
}

Обратно несъвместимо преименуване на колони

Нека да разгледаме пример как да промените името на колона:

внимание. Следващият пример умишлено ще наруши нещата. Показваме това, за да демонстрираме проблема със съвместимостта на базата данни.

Версия на приложението: 2.0.0.BAD

DB версия: v2bad

Коментар

Текущите промени НЕ ни позволяват да изпълняваме две инстанции (стара и нова) едновременно. По този начин ще бъде трудно да се постигне внедряване с нулево време на престой (ако се вземат предвид допусканията, всъщност е невъзможно).

A/B тестване

Текущата ситуация е, че имаме версия на приложението 1.0.0, внедрени в производство и база данни v1. Трябва да внедрим второ копие на приложението, версия 2.0.0.BADи актуализирайте базата данни до v2bad.

стъпки:

1. е внедрен нов екземпляр на приложението за версия 2.0.0.BADкойто актуализира базата данни до v2bad
2. в базата данни v2bad колона last_name вече не съществува - беше променено на surname
3. Актуализацията на базата данни и приложението беше успешна и някои копия се изпълняват 1.0.0, други - в 2.0.0.BAD. Всичко е свързано с базата данни v2bad
4. всички екземпляри на версията 1.0.0 ще започнат да извеждат грешки, защото ще се опитат да вмъкнат данни в колоната last_nameкойто вече не съществува
5. всички екземпляри на версията 2.0.0.BAD ще работи без проблеми

Както можете да видите, ако направим обратно несъвместими промени в базата данни и приложението, A/B тестването е невъзможно.

Връщане на приложението

Да приемем, че след като се опитате да извършите A/B внедряване (прибл. per.: тук авторът вероятно е имал предвид A/B тестване) решихме, че трябва да върнем приложението до версията 1.0.0. Да кажем, че не искаме да върнем базата данни.

стъпки:

1. спираме екземпляра на приложението за версия 2.0.0.BAD
2. базата данни е все още v2bad
3. тъй като версията 1.0.0 не разбира какво е surname, ще видим грешки
4. адът избухна, не можем да се върнем повече

Както можете да видите, ако направим обратно несъвместими промени в базата данни и приложението, не можем да се върнем към предишната версия.

Журнали за изпълнение на скриптове

Backward incompatible scenario:

01) Run 1.0.0
02) Wait for the app (1.0.0) to boot
03) Generate a person by calling POST localhost:9991/person to version 1.0.0
04) Run 2.0.0.BAD
05) Wait for the app (2.0.0.BAD) to boot
06) Generate a person by calling POST localhost:9991/person to version 1.0.0 <-- this should fail
07) Generate a person by calling POST localhost:9992/person to version 2.0.0.BAD <-- this should pass

Starting app in version 1.0.0
Generate a person in version 1.0.0
Sending a post to 127.0.0.1:9991/person. This is the response:

{"firstName":"b73f639f-e176-4463-bf26-1135aace2f57","lastName":"b73f639f-e176-4463-bf26-1135aace2f57"}

Starting app in version 2.0.0.BAD
Generate a person in version 1.0.0
Sending a post to 127.0.0.1:9991/person. This is the response:

curl: (22) The requested URL returned error: 500 Internal Server Error

Generate a person in version 2.0.0.BAD
Sending a post to 127.0.0.1:9995/person. This is the response:

{"firstName":"e156be2e-06b6-4730-9c43-6e14cfcda125","surname":"e156be2e-06b6-4730-9c43-6e14cfcda125"}

Промени в базата данни

Скрипт за миграция, който преименува last_name в surname

Изходен скрипт на Flyway:

CREATE TABLE PERSON (
id BIGINT GENERATED BY DEFAULT AS IDENTITY,
first_name varchar(255) not null,
last_name varchar(255) not null
);

insert into PERSON (first_name, last_name) values ('Dave', 'Syer');

Скрипт, който преименува last_name.

-- This change is backward incompatible - you can't do A/B testing
ALTER TABLE PERSON CHANGE last_name surname VARCHAR;

Промени в кода

Променихме името на полето lastName на surname.

Преименуване на колона по обратно съвместим начин

Това е най-честата ситуация, с която можем да се сблъскаме. Трябва да направим обратно несъвместими промени. Вече доказахме, че за внедряване без прекъсване не трябва просто да прилагаме миграция на база данни без допълнителни стъпки. В този раздел на статията ще извършим 3 внедрявания на приложението заедно с миграции на бази данни, за да постигнем желания резултат, като същевременно поддържаме обратна съвместимост.

Бележката. Спомнете си, че имаме база данни с версии v1. Съдържа колони first_name и last_name. Трябва да се променим last_name на surname. Имаме и версия на приложението 1.0.0, който все още не се използва surname.

Стъпка 2: Добавете фамилия

Версия на приложението: 2.0.0
DB версия: v2

Коментар

Чрез добавяне на нова колона и копиране на нейното съдържание, ние създаваме обратно съвместими промени в базата данни. В същото време, ако върнем JAR назад или стартираме стар JAR, той няма да се повреди по време на изпълнение.

Пускаме нова версия

стъпки:

1. извършете миграция на база данни, за да създадете нова колона surname. Сега вашата DB версия v2
2. копиране на данни от last_name в surname. Моля, обърнете вниманиече ако имате много от тези данни, трябва да помислите за пакетна миграция!
3. напишете кода, където се използват И ДВЕТЕ и новИ старата колона. Сега вашата версия на приложението 2.0.0
4. прочетете стойността от колоната surname, ако не е null, или от лast_name, ако surname неопределено. Можете да изтриете getLastName() от кода, тъй като ще изведе null когато връщате приложението си от 3.0.0 до 2.0.0.

Ако използвате Spring Boot Flyway, тези две стъпки ще бъдат изпълнени по време на стартиране на версията 2.0.0 приложения. Ако стартирате инструмента за версия на базата данни ръчно, ще трябва да направите две различни неща, за да направите това (първо актуализирайте ръчно версията на db и след това внедрите новото приложение).

Това е важно. Не забравяйте, че новосъздадената колона НЕ ТРЯБВА бъде НЕ Е НУЛНО. Ако направите връщане назад, старото приложение не знае за новата колона и няма да го инсталира по време Insert. Но ако добавите това ограничение и вашият db ще бъде v2, това ще изисква задаване на стойността на новата колона. Което ще доведе до нарушаване на ограниченията.

Това е важно. Трябва да премахнете метода getLastName(), тъй като във версията 3.0.0 В кода няма концепция за колона last_name. Това означава, че там ще бъде зададена нула. Можете да оставите метода и да добавите проверки за null, но много по-добро решение би било да се уверите, че в логиката getSurname() сте избрали правилната ненулева стойност.

A/B тестване

Текущата ситуация е, че имаме версия на приложението 1.0.0, разгърнати в производството и базата данни в v1. Трябва да внедрим второ копие на приложението за версия 2.0.0който ще актуализира базата данни до v2.

стъпки:

1. е внедрен нов екземпляр на приложението за версия 2.0.0който актуализира базата данни до v2
2. междувременно някои заявки бяха обработени от екземпляри на версия 1.0.0
3. актуализацията беше успешна и имате множество работещи екземпляри на приложението за версия 1.0.0 и други версии 2.0.0. Всеки комуникира с базата данни в v2
4. версия 1.0.0 не използва колоната за фамилия в базата данни, а версията 2.0.0 използва. Те не си пречат и не трябва да има грешки.
5. версия 2.0.0 съхранява данни както в старата, така и в новата колона, осигурявайки обратна съвместимост

Това е важно. Ако имате някакви заявки, които броят елементи въз основа на стойности от старата/новата колона, трябва да запомните, че сега имате дублиращи се стойности (най-вероятно те все още мигрират). Например, ако искате да преброите броя на потребителите, чието фамилно име (както и да се нарича колоната) започва с буквата A, след което докато миграцията на данните приключи (old → new колона) може да имате непоследователни данни, ако заявите нова колона.

Връщане на приложението

Сега имаме версия на приложението 2.0.0 и база данни в v2.

стъпки:

1. върнете приложението си до версия 1.0.0.
2. версия 1.0.0 не използва колона в базата данни surname, така че връщането назад трябва да е успешно

Промени в БД

Базата данни съдържа колона с име last_name.

Изходен скрипт на Flyway:

CREATE TABLE PERSON (
id BIGINT GENERATED BY DEFAULT AS IDENTITY,
first_name varchar(255) not null,
last_name varchar(255) not null
);

insert into PERSON (first_name, last_name) values ('Dave', 'Syer');

Добавяне на скрипт surname.

внимание. Не забравяйте, че НЕ МОЖЕТЕ ДА ДОБАВЯТЕ никакви NOT NULL ограничения към колоната, която добавяте. Ако върнете JAR, старата версия няма да има представа за добавената колона и автоматично ще я зададе на NULL. Ако има такова ограничение, старото приложение просто ще се счупи.

-- NOTE: This field can't have the NOT NULL constraint cause if you rollback, the old version won't know about this field
-- and will always set it to NULL
ALTER TABLE PERSON ADD surname varchar(255);

-- WE'RE ASSUMING THAT IT'S A FAST MIGRATION - OTHERWISE WE WOULD HAVE TO MIGRATE IN BATCHES
UPDATE PERSON SET PERSON.surname = PERSON.last_name

Промени в кода

Ние съхраняваме данни като last_name, и в surname. В същото време четем от last_name, тъй като тази колона е най-подходяща. По време на процеса на внедряване някои заявки може да са били обработени от екземпляр на приложение, който все още не е актуализиран.

/*
 * Copyright 2012-2016 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package sample.flyway;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Long id;
    private String firstName;
    private String lastName;
    private String surname;

    public String getFirstName() {
        return this.firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    /**
     * Reading from the new column if it's set. If not the from the old one.
     *
     * When migrating from version 1.0.0 -> 2.0.0 this can lead to a possibility that some data in
     * the surname column is not up to date (during the migration process lastName could have been updated).
     * In this case one can run yet another migration script after all applications have been deployed in the
     * new version to ensure that the surname field is updated.
     *
     * However it makes sense since when looking at the migration from 2.0.0 -> 3.0.0. In 3.0.0 we no longer
     * have a notion of lastName at all - so we don't update that column. If we rollback from 3.0.0 -> 2.0.0 if we
     * would be reading from lastName, then we would have very old data (since not a single datum was inserted
     * to lastName in version 3.0.0).
     */
    public String getSurname() {
        return this.surname != null ? this.surname : this.lastName;
    }

    /**
     * Storing both FIRST_NAME and SURNAME entries
     */
    public void setSurname(String surname) {
        this.lastName = surname;
        this.surname = surname;
    }

    @Override
    public String toString() {
        return "Person [firstName=" + this.firstName + ", lastName=" + this.lastName + ", surname=" + this.surname
                + "]";
    }
}

Стъпка 3: Премахване на last_name от кода

Версия на приложението: 3.0.0

DB версия:v3

Коментар

Забележка per.: Очевидно в оригиналната статия авторът погрешка е копирал текста на този блок от стъпка 2. На тази стъпка трябва да се направят промени в кода на приложението, насочени към премахване на функционалността, която използва колоната last_name.

Чрез добавяне на нова колона и копиране на нейното съдържание създадохме обратно съвместими промени в базата данни. Също така, ако върнем JAR назад или стартираме стар JAR, той няма да се повреди по време на изпълнение.

Връщане на приложението

В момента имаме версия на приложението 3.0.0 и база данни v3. Версия 3.0.0 не записва данни в last_name. Това означава, че в surname се съхранява най-актуалната информация.

стъпки:

1. върнете приложението си до версия 2.0.0.
2. версия 2.0.0 използва и last_name и surname.
3. версия 2.0.0 ще взема surname, ако не е нула, в противен случай -last_name

Промени в базата данни

Няма структурни промени в базата данни. Следният скрипт се изпълнява за извършване на окончателната миграция на старите данни:

-- WE'RE ASSUMING THAT IT'S A FAST MIGRATION - OTHERWISE WE WOULD HAVE TO MIGRATE IN BATCHES
-- ALSO WE'RE NOT CHECKING IF WE'RE NOT OVERRIDING EXISTING ENTRIES. WE WOULD HAVE TO COMPARE
-- ENTRY VERSIONS TO ENSURE THAT IF THERE IS ALREADY AN ENTRY WITH A HIGHER VERSION NUMBER
-- WE WILL NOT OVERRIDE IT.
UPDATE PERSON SET PERSON.surname = PERSON.last_name;

-- DROPPING THE NOT NULL CONSTRAINT; OTHERWISE YOU WILL TRY TO INSERT NULL VALUE OF THE LAST_NAME
-- WITH A NOT_NULL CONSTRAINT.
ALTER TABLE PERSON MODIFY COLUMN last_name varchar(255) NULL DEFAULT NULL;

Промени в кода

Забележка пер.: Описанието на този блок също беше погрешно копирано от автора от стъпка 2. В съответствие с логиката на статията промените в кода на тази стъпка трябва да са насочени към премахване от него на елементи, които работят с колоната last_name.

Ние съхраняваме данни като last_name, и в surname. Освен това четем от колоната last_name, тъй като е най-актуален. По време на процеса на внедряване някои заявки може да бъдат обработени от екземпляр, който все още не е надстроен.

/*
 * Copyright 2012-2016 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package sample.flyway;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Long id;
    private String firstName;
    private String surname;

    public String getFirstName() {
        return this.firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getSurname() {
        return this.surname;
    }

    public void setSurname(String lastname) {
        this.surname = lastname;
    }

    @Override
    public String toString() {
        return "Person [firstName=" + this.firstName + ", surname=" + this.surname
                + "]";
    }
}

Стъпка 4: Премахване на last_name от базата данни

Версия на приложението: 4.0.0

DB версия: v4

Коментар

Поради факта, че кодът на версията 3.0.0 не използва колоната last_name, няма да се случи нищо лошо по време на изпълнение, ако се върнем към 3.0.0 след премахване на колона от базата данни.

Журнали за изпълнение на скриптове

We will do it in the following way:

01) Run 1.0.0
02) Wait for the app (1.0.0) to boot
03) Generate a person by calling POST localhost:9991/person to version 1.0.0
04) Run 2.0.0
05) Wait for the app (2.0.0) to boot
06) Generate a person by calling POST localhost:9991/person to version 1.0.0
07) Generate a person by calling POST localhost:9992/person to version 2.0.0
08) Kill app (1.0.0)
09) Run 3.0.0
10) Wait for the app (3.0.0) to boot
11) Generate a person by calling POST localhost:9992/person to version 2.0.0
12) Generate a person by calling POST localhost:9993/person to version 3.0.0
13) Kill app (3.0.0)
14) Run 4.0.0
15) Wait for the app (4.0.0) to boot
16) Generate a person by calling POST localhost:9993/person to version 3.0.0
17) Generate a person by calling POST localhost:9994/person to version 4.0.0

Starting app in version 1.0.0
Generate a person in version 1.0.0
Sending a post to 127.0.0.1:9991/person. This is the response:

{"firstName":"52b6e125-4a5c-429b-a47a-ef18bbc639d2","lastName":"52b6e125-4a5c-429b-a47a-ef18bbc639d2"}

Starting app in version 2.0.0

Generate a person in version 1.0.0
Sending a post to 127.0.0.1:9991/person. This is the response:

{"firstName":"e41ee756-4fa7-4737-b832-e28827a00deb","lastName":"e41ee756-4fa7-4737-b832-e28827a00deb"}

Generate a person in version 2.0.0
Sending a post to 127.0.0.1:9992/person. This is the response:

{"firstName":"0c1240f5-649a-4bc5-8aa9-cff855f3927f","lastName":"0c1240f5-649a-4bc5-8aa9-cff855f3927f","surname":"0c1240f5-649a-4bc5-8aa9-cff855f3927f"}

Killing app 1.0.0

Starting app in version 3.0.0

Generate a person in version 2.0.0
Sending a post to 127.0.0.1:9992/person. This is the response:
{"firstName":"74d84a9e-5f44-43b8-907c-148c6d26a71b","lastName":"74d84a9e-5f44-43b8-907c-148c6d26a71b","surname":"74d84a9e-5f44-43b8-907c-148c6d26a71b"}

Generate a person in version 3.0.0
Sending a post to 127.0.0.1:9993/person. This is the response:
{"firstName":"c6564dbe-9ab5-40ae-9077-8ae6668d5862","surname":"c6564dbe-9ab5-40ae-9077-8ae6668d5862"}

Killing app 2.0.0

Starting app in version 4.0.0

Generate a person in version 3.0.0
Sending a post to 127.0.0.1:9993/person. This is the response:

{"firstName":"cbe942fc-832e-45e9-a838-0fae25c10a51","surname":"cbe942fc-832e-45e9-a838-0fae25c10a51"}

Generate a person in version 4.0.0
Sending a post to 127.0.0.1:9994/person. This is the response:

{"firstName":"ff6857ce-9c41-413a-863e-358e2719bf88","surname":"ff6857ce-9c41-413a-863e-358e2719bf88"}

Промени в БД

За v3 просто премахваме колоната last_name и добавете липсващи ограничения.

-- REMOVE THE COLUMN
ALTER TABLE PERSON DROP last_name;

-- ADD CONSTRAINTS
UPDATE PERSON SET surname='' WHERE surname IS NULL;
ALTER TABLE PERSON ALTER COLUMN surname VARCHAR NOT NULL;

Промени в кода

Няма промени в кода.

Продукция

Успешно приложихме обратно несъвместима промяна на името на колона, като изпълнихме няколко обратно съвместими внедрявания. По-долу е обобщено извършените действия:

1. внедряване на версия на приложението 1.0.0 с v1 схема на база данни (име на колона = last_name)
2. внедряване на версия на приложението 2.0.0, който съхранява данни в last_name и surname. Приложението чете от last_name. Базата данни е във версия v2съдържащи колони като last_nameИ surname. surname е копие на лast_name. (ЗАБЕЛЕЖКА: Тази колона не трябва да има ограничение не нула)
3. внедряване на версия на приложението 3.0.0, който съхранява данни само в surname и се чете от фамилията. Що се отнася до базата данни, последната миграция се извършва last_name в surname. Също ограничение НЕ Е НУЛНО премахнат от last_name. Базата данни вече е във версия v3
4. внедряване на версия на приложението 4.0.0 - не се правят промени в кода. Разгръщане на база данни v4, който премахва last_name. Тук можете да добавите всички липсващи ограничения към базата данни.

Като следвате този подход, винаги можете да върнете една версия назад, без да нарушавате съвместимостта на база данни/приложение.

Код

Целият код, използван в тази статия, е достъпен на Github. По-долу има допълнително описание.

проекти

След като клонирате хранилището, ще видите следната структура на папките.

├── boot-flyway-v1              - 1.0.0 version of the app with v1 of the schema
├── boot-flyway-v2              - 2.0.0 version of the app with v2 of the schema (backward-compatible - app can be rolled back)
├── boot-flyway-v2-bad          - 2.0.0.BAD version of the app with v2bad of the schema (backward-incompatible - app cannot be rolled back)
├── boot-flyway-v3              - 3.0.0 version of the app with v3 of the schema (app can be rolled back)
└── boot-flyway-v4              - 4.0.0 version of the app with v4 of the schema (app can be rolled back)

Scripts

Можете да стартирате скриптовете, описани в скриптовете по-долу, които ще демонстрират обратно съвместими и несъвместими промени в базата данни.

За да видите случаят с обратно съвместими промени, стартирайте:

./scripts/scenario_backward_compatible.sh

И да видя случай с обратно несъвместими промени, стартирайте:

./scripts/scenario_backward_incompatible.sh

Примерен Flyway за пролетно зареждане

Всички примери са взети от Spring Boot Sample Flyway.

Можете да разгледате http://localhost:8080/flyway, има списък със скриптове.

Този пример включва и конзолата H2 (в http://localhost:8080/h2-console), така че можете да видите състоянието на базата данни (URL адресът по подразбиране на jdbc е jdbc:h2:mem:testdb).

Освен това

• Модели за рефакторинг на бази данни
• Continuous Delivery

Прочетете и други статии в нашия блог:

• Kubernetes: защо е толкова важно да настроите управление на системните ресурси?
• Tekton Pipeline - собствени тръбопроводи на Kubernetes
• Изграждане на динамични модули за Nginx
• Въведение в разрешението за Kubernetes на Hashicorp Consul
• До какво доведе миграцията от ClickHouse без авторизация към ClickHouse с авторизация?
• Синьо-зелено внедряване на Spring приложения с уеб сървър Nginx

Източник: www.habr.com