Статьи

Agile Базы данных

Февраль 17, 2019

Любой проект, следуя методологии Agile, обычно выпускается в производство не менее 15–20 раз в год. Даже если только половина из этих выпусков включает изменения в базе данных, это 10 изменений в производственных базах данных, поэтому вам нужен хороший бережливый процесс, чтобы убедиться, что вы получаете хороший бумажный след, но в то же время вам не нужно что-то, что замедлит вас просто излишне вниз. Итак, несколько советов на этот счет:

Совет 1: представьте таблицу журнала БД

Используйте таблицу журнала БД для записи каждого запускаемого скрипта, кто его запускал, когда он был запущен, с каким билетом он был связан и т. Д. Вот пример DDL для такой таблицы для PostGres:

1
2
create sequence db_log_id_seq;
create table db_log (id int8 not null DEFAULT nextval('db_log_id_seq'), created timestamp not null,  db_owner varchar(255), db_user varchar(255), project_version varchar(255), script_link varchar(255), jira varchar(255));

WRT столбцы таблицы:

  • id — первичный ключ для таблицы.
  • метка времени — время запуска скрипта. Это полезно Поверь мне.
  • db_owner — пользователь, который выполнил скрипт.
  • db_user — пользователь, который написал скрипт
  • project_version_number — версия вашего приложения / проекта, в котором был сгенерирован скрипт.
  • scrip_link — URL-ссылка на версию скрипта, контролируемую источником
  • jira — URL-адрес заявки, связанной со сценарием.

Совет 2: Все сценарии должны быть транзакционными

Для каждого сценария убедитесь, что это происходит внутри транзакции, а внутри транзакции убедитесь, что есть соответствующая запись в таблице журнала базы данных. Например, вот скрипт, который удаляет столбец

01
02
03
04
05
06
07
08
09
10
11
12
13
BEGIN;
ALTER TABLE security.platform_session DROP COLUMN IF EXISTS ttl;
INSERT INTO db_log (
       db_owner, db_user, project_version, script_link, jira, created)
VALUES (
       current_user,
       'alexstaveley',
       '1.1.4',
       'http://ldntools/labs/cp/blob/master/platform/scripts/db/updates/1.1.4/CP-643.sql',
       'CP-643',
       current_timestamp
);
COMMIT;

Совет 3: сценарии должны быть идемпотентными

Попробуйте сделать сценарии идемпотентными. Если в команде 10 разработчиков, то время от времени кто-то дважды запускает скрипт случайно. Ваш db_log скажет вам об этом, но постарайтесь, чтобы в случае несчастных случаев не было серьезных повреждений. Это означает, что вы получите простой
отказоустойчивый, а не какой-то новичок, волнующийся. В приведенном выше сценарии, если он выполняется дважды, ответ будет точно таким же.

Совет 4: Source Control вашей схемы

Исходный контроль мастер DDL для всего проекта. Это обновляется каждый раз, когда меняется схема. Это означает, что у вас есть сценарии обновления
и полный мастер-скрипт, содержащий DDL для всего проекта. Главный скрипт запускается в начале каждого CI, что означает, что:

  • Ваш CI всегда начинается с чистой базы данных
  • Если разработчик забудет обновить мастер-скрипт, CI потерпит неудачу, и ваша команда быстро узнает, что мастер-скрипт необходимо обновить.
  • Когда у вас есть мастер-скрипт, он дает вам два явных преимущества:
    • Новые разработчики очень быстро начинают работать с чистой базой данных
    • Становится очень легко создавать новые среды. Просто запустите мастер-скрипт!

Совет 5: будьте дружелюбны к Dev

Сделайте так, чтобы разработчики могли легко создавать мастер-сценарии. В противном случае, когда тепло включено, это не будет сделано.

Совет 6: обновить и вернуть

Для каждого сценария обновления напишите соответствующий сценарий возврата. Что-то неожиданное случается в производстве, ты должен быть в состоянии перевернуть грузовик обратно!

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
BEGIN;
 
ALTER TABLE security.platform_session ADD COLUMN hard_ttl INT4;
UPDATE security.platform_session  SET hard_ttl = -1 WHERE hard_ttl IS NULL;
ALTER TABLE security.platform_session ALTER COLUMN hard_ttl SET NOT NULL;
 
ALTER TABLE security.platform_session ADD COLUMN ttl INT4;
UPDATE security.platform_session  SET ttl = -1 WHERE ttl IS NULL;
ALTER TABLE security.platform_session ALTER COLUMN ttl SET NOT NULL;
 
 
INSERT INTO db_log (
       db_owner, db_user, platform_version, script_link, jira, created)
       values (
       current_user,
       'alexstaveley',
       '1.1.4',
       'http://ldntools/labs/cp/blob/master/platform/scripts/db/reverts/1.1.4/revert-CP-463.sql',
       'CP-463',
       current_timestamp
    );
 
COMMIT;

До следующего раза береги себя.

Ссылка: Гибкие базы данных от нашего партнера JCG Алекса Стейвли в блоге Tech Blog в Дублине .
39
Share: