Примена и базе података без застоја

Овај чланак детаљно објашњава како да решите проблеме са компатибилношћу базе података у примени. Рећи ћемо вам шта се може догодити вашим производним апликацијама ако покушате да их примените без прелиминарне припреме. Затим ћемо проћи кроз фазе животног циклуса апликације за које је потребно да немају застоја (прибл. трака: даље - нула застоја). Резултат наших операција биће да применимо назад некомпатибилну промену базе података на начин компатибилан са уназад.

Ако желите да разумете примере кода из чланка, можете их пронаћи на ГитХуб.

Увод

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

Каква мистика нула застоја у примени? Можете рећи да је то када је ваша апликација распоређена на начин да можете успешно увести нову верзију апликације у производњу, а да корисник не примети њену недоступност. Из перспективе корисника и компаније, ово је најбољи могући сценарио примене јер омогућава увођење нових функција и исправљање грешака без ометања.

Како то постићи? Постоји неколико начина, ево једног од њих:

• примените верзију бр. 1 своје услуге
• изврши миграцију базе података
• Поставите верзију #2 своје услуге паралелно са верзијом #1
• чим видите да верзија бр.2 ради како треба, уклоните верзију бр.1
• готов!

Лако, зар не? Нажалост, то није тако једноставно, а касније ћемо то детаљније погледати. Сада хајде да проверимо још један прилично уобичајен процес постављања - плаво зелено распоређивање.

Јесте ли икада чули за плаво зелено распоређивање? Цлоуд Фоундри ово чини изузетно лаким. Само погледајте овај чланак, где ово детаљније описујемо. Да укратко резимирамо, подсетимо вас како да примените плаво зелено:

• обезбедите да две копије вашег производног кода („плава“ и „зелена“) раде;
• сав саобраћај усмерити на плаво окружење, тј. тако да производне УРЛ адресе упућују тамо;
• применити и тестирати све промене апликација у зеленом окружењу;
• промените УРЛ из плавог у зелено окружење

Плаво зелена примена је приступ који вам омогућава да лако уведете нове функције без бриге о прекиду производње. То је због чињенице да чак и ако се нешто догоди, лако се можете вратити на претходно окружење једноставним „пребацивањем прекидача“.

Након што прочитате све горе наведено, можете поставити питање: Какве везе нулти застој има са применом плаво зелене боје?

Па, имају доста тога заједничког, пошто одржавање две копије истог окружења захтева двоструки напор да се оне одрже. Због тога неки тимови тврде Мартин Фовлер, пратите варијацију овог приступа:

Друга опција је да користите исту базу података, креирајући плаво-зелене прекидаче за веб и слојеве домена. У овом приступу база података често може представљати проблем, посебно када треба да промените њену шему да бисте подржали нову верзију софтвера.

И овде долазимо до главног проблема у овом чланку. База података. Хајде да још једном погледамо ову фразу.

изврши миграцију базе података.

Сада морате да се запитате – шта ако промена базе података није компатибилна унатраг? Зар се моја прва верзија апликације неће покварити? У ствари, управо то ће се догодити...

Дакле, чак и упркос огромним предностима нулте застоје / плаво зелене примене, компаније имају тенденцију да следе следећи сигурнији процес за имплементацију својих апликација:

• припремите пакет са новом верзијом апликације
• искључите покренуту апликацију
• покрените скрипте за миграцију базе података
• применити и покренути нову верзију апликације

У овом чланку ћемо детаљно описати како можете да радите са својом базом података и кодом да бисте искористили предности примене без застоја.

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

Ако имате апликацију без стања која не складишти никакве податке у бази података, одмах можете добити нулту примену застоја. Нажалост, већина софтвера мора негде да ускладишти податке. Због тога треба двапут размислити пре него што унесете било какве промене у коло. Пре него што уђемо у детаље о томе како да променимо шему тако да је могућа примена без застоја, хајде да се прво фокусирамо на шему верзионисања.

Шема верзија

У овом чланку ћемо користити Фливаи као алат за контролу верзија (прибл. Превод: говоримо о миграцијама базе података). Наравно, такође ћемо написати Спринг Боот апликацију која има уграђену подршку за Фливаи и која ће вршити миграцију шеме током подешавања контекста апликације. Када користите Фливаи, можете да складиштите скрипте за миграцију у фасциклу са пројектима (подразумевано у 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');

Све је савршено само по себи разумљиво: можете користити СКЛ да дефинишете како ваша база података треба да буде модификована. За више информација о Спринг Боот-у и Фливаи-у, погледајте Спринг Боот Доцс.

Коришћењем алата за контролу извора са Спринг Боот-ом, добијате 2 велике предности:

• одвајате промене базе података од промена кода
• Миграција базе података се дешава заједно са увођењем ваше апликације, тј. ваш процес постављања је поједностављен

Решавање проблема са базом података

У следећем одељку чланка, фокусираћемо се на разматрање два приступа променама базе података.

• назадна некомпатибилност
• Компатибилност

Први ће се сматрати упозорењем да не треба да вршите имплементацију нултог застоја без претходне припреме... Други нуди решење како да извршите имплементацију без застоја, а да истовремено одржите компатибилност уназад.

Наш пројекат на којем ћемо радити биће једноставна Спринг Боот Фливаи апликација која има Person с first_name и last_name у бази података (прибл. превод: Person је табела и фirst_name и last_name - ово су поља у њему). Желимо да преименујемо last_name в surname.

Претпоставке

Пре него што уђемо у детаље, потребно је да направимо неколико претпоставки о нашим апликацијама. Главни резултат који желимо да постигнемо биће прилично једноставан процес.

Белешка. Пословни ПРО-ТИП. Поједностављивање ваших процеса може вам уштедети много новца на подршци (што више људи радите за вашу компанију, више новца можете уштедети)!

Нема потребе за враћањем базе података

Ово поједностављује процес имплементације (нека враћања базе података су скоро немогућа, као што је враћање брисања). Радије враћамо само апликације. На овај начин, чак и ако имате различите базе података (на пример, СКЛ и НоСКЛ), ваш цевовод за примену ће изгледати исто.

Увек мора бити могуће вратити апликацију за једну верзију уназад (не више)

Враћање треба да се врши само када је то неопходно. Ако постоји грешка у тренутној верзији коју није лако поправити, требало би да будемо у могућности да се вратимо на најновију радну верзију. Претпостављамо да је ова најновија радна верзија претходна. Одржавање компатибилности кода и базе података за више од једног покретања било би изузетно тешко и скупо.

Белешка. Ради веће читљивости, у овом чланку ћемо променити главну верзију апликације.

Корак 1: Почетно стање

Верзија апликације: 1.0.0
ДБ верзија: v1

Коментар

Ово ће бити почетно стање апликације.

Промене базе података

ДБ садржи 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

ДБ верзија: v2bad

Коментар

Тренутне промене нам НЕ дозвољавају да истовремено покрећемо две инстанце (старе и нове). Стога ће бити тешко постићи нулту имплементацију застоја (ако се узму у обзир претпоставке, то је заправо немогуће).

А/Б тестирање

Тренутна ситуација је да имамо верзију апликације 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 радиће без проблема

Као што видите, ако извршимо уназад некомпатибилне промене у бази података и апликацији, А/Б тестирање је немогуће.

Враћање апликације

Претпоставимо да након покушаја имплементације А/Б (прибл. пер.: аутор је овде вероватно мислио на А/Б тестирање) одлучили смо да морамо да вратимо апликацију на верзију 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

Извор Фливаи скрипта:

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
ДБ верзија: v2

Коментар

Додавањем нове колоне и копирањем њеног садржаја, креирамо назад компатибилне промене базе података. У исто време, ако вратимо ЈАР или покренемо стари ЈАР, он се неће покварити током извршавања.

Представљамо нову верзију

Кораци:

1. извршите миграцију базе података да бисте креирали нову колону surname. Сада ваша ДБ верзија v2
2. копирај податке из last_name в surname. Обратите вниманиеда ако имате много ових података, требало би да размислите о пакетној миграцији!
3. напишите код где се користе ОБОЈЕ и новиИ стари колона. Сада ваша верзија апликације 2.0.0
4. прочитајте вредност из колоне surname, ако није null, или од лast_nameако surname није прецизирано. Можете избрисати getLastName() из кода, пошто ће он исписати null приликом враћања апликације са 3.0.0 до 2.0.0.

Ако користите Спринг Боот Фливаи, ова два корака ће се извршити током покретања верзије 2.0.0 апликације. Ако ручно покренете алатку за одређивање верзија базе података, мораћете да урадите две различите ствари да бисте то урадили (прво ручно ажурирајте верзију дб-а, а затим примените нову апликацију).

Важно је. Запамтите да је новостворена колона НЕ ТРЕБА бити НОТ НУЛЛ. Ако извршите враћање, стара апликација не зна за нову колону и неће је инсталирати током Insert. Али ако додате ово ограничење и ваш дб ће бити v2, ово ће захтевати подешавање вредности нове колоне. Што ће довести до кршења ограничења.

Важно је. Требало би да уклоните метод getLastName(), јер у верзији 3.0.0 У коду не постоји концепт колоне last_name. То значи да ће тамо бити постављена нула. Можете оставити метод и додати провере за null, али би много боље решење било да се у то уверимо у логици getSurname() изабрали сте исправну вредност која није нула.

А/Б тестирање

Тренутна ситуација је да имамо верзију апликације 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.

Изворна скрипта Фливаи:

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.

Пажња. Запамтите да НЕ МОЖЕТЕ ДОДАТИ никаква НОТ НУЛЛ ограничења у колону коју додајете. Ако вратите ЈАР, стара верзија неће имати појма о додатој колони и аутоматски ће је поставити на НУЛЛ. Ако постоји такво ограничење, стара апликација ће се једноставно покварити.

-- 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: Уклањање презимена из кода

Верзија апликације: 3.0.0

ДБ верзија:v3

Коментар

Белешка пер.: Очигледно је у оригиналном чланку аутор грешком копирао текст овог блока из корака 2. У овом кораку треба извршити измене у коду апликације са циљем да се уклони функционалност која користи колону last_name.

Додавањем нове колоне и копирањем њеног садржаја, направили смо уназад компатибилне промене базе података. Такође, ако вратимо ЈАР или покренемо стари ЈАР, он се неће покварити током извршавања.

Враћање апликације

Тренутно имамо верзију апликације 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: Уклањање презимена из базе података

Верзија апликације: 4.0.0

ДБ верзија: 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. Овде можете додати сва ограничења која недостају у базу података.

Пратећи овај приступ, увек можете да вратите једну верзију уназад без нарушавања компатибилности базе података/апликација.

Код

Сав код коришћен у овом чланку доступан је на Гитхуб. Испод је додатни опис.

Пројекти

Након клонирања спремишта, видећете следећу структуру фасцикли.

├── 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/scenario_backward_compatible.sh

И да видим случај са назад некомпатибилним променама, трцати:

./scripts/scenario_backward_incompatible.sh

Пролећни узорак за пролеће

Сви примери су преузети из Spring Boot Sample Flyway.

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

Овај пример такође укључује конзолу Х2 (на http://localhost:8080/h2-console) тако да можете да видите статус базе података (подразумевана јдбц УРЛ адреса је jdbc:h2:mem:testdb).

додатно

• Обрасци рефакторисања базе података
• Континуирана достава

Прочитајте и друге чланке на нашем блогу:

• Кубернетес: зашто је толико важно конфигурисати управљање системским ресурсима?
• Тектон Пипелине - Кубернетес изворни цевовод
• Израда динамичких модула за Нгинк
• Увод у Кубернетес овлашћење Хасхицорп конзула
• До чега је довела миграција са ЦлицкХоусе без овлашћења на ЦлицкХоусе са овлашћењем?
• Плаво-зелена примена Спринг апликација са Нгинк веб сервером

Извор: ввв.хабр.цом