Просмотр исходного текста страницы Максим Цепков - AgileDays-2011/Непрерывная интеграция при разработке баз данных

* [[Непрерывная интеграция при разработке баз данных (Владимир Бахов, AgileDays-2011)]]

Пионер — относительно нас, мы примерно так со скриптами полного проноса или изменений работали лет 5 назад и ранее. Переход от ручного наката к версионным скриптам и постепенном накате изменений.
Но то, что сделано — работает. Народа было много, тема людям интересна.
Я все-таки позиционировал этот доклад к докладам о новом опыте, не столько потому, что мы впереди, сколько потому, что рассказывалось без вариаций о том способе, который они сейчас применяют, без связи с окружением мирового опыта. А сами они — работают одним способом.

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

'''Заметки.'''
* Началось все как-то примитивно, когда был просто ручная сборка скриптов и накат, нет версионности БД, несоответствие тестовой и боевой по производительности и т. п.
* И вообще скриптовый build-инженер ушел в отпуск — жопа
* Я еще мяч между dba и разработчиков. Да еще когда поставка на площадку, где накатывают другие люди.
* Якобы все решает непрерывная интеграция. Я: На самом деле — совсем не все, то о чем он говорит — это просто наличие тестовых площадках, а непрерывная интеграция — про другое.

{{remark|[[Участник:StasFomin|Стас Фомин]]:Собственно это [[Обсуждение блога:Стас Фомин/AgileDays-preview (Совершенно Секретно!)/c001991|я говорил автору еще на этапе ревью]]. И впечатлил оного — после доклада он подходил ко мне, чтобы я посоветовал ему гуру непрерывной интерграции — я послал его к вам и Игорю Беспальчуку (сам был в полном мыле, общатся не мог), не знаю, дошел ли он до наших.}}
* Что есть БД — в ней много данных, надо накатывать изменения, делать миграцию и прочее.
* В общем, с БД сложнее, чем с веб-приложениями.
* Особенно откат на предыдущую версию. Например, drop table.
* Есть проблемы с продуктами, поддерживающими CI…
* 15 минут внедрения. потом решение — да, это можно.
* Что надо: <tt>svn</tt> + <tt>UTPLsql</tt> (сейчас у Oracle в sqldev что-то вышло)
* Задача первая — все менять скриптами.
* Для начала — надо снять текущий слепок кодов проекта prod (по умолчанию исходных кодов нет). Снимают в директории по типам объектов. И именуют с цифрами для правильной сортировке.
* Есть trunc. А дальше — diff между trunc и prod. И накатываем. Продуктив один (хотя там можно по версиям, наверное). Специально добавляют какие-то скрипты и пишут их вручную. По вопросам — надеялись и это автоматом сделать.
* Урезанная продуктивная база для синтетического тестирования.
* Важны функциональные синтетические тесты.
* Поднятие локальной базы — для всех разработчиков. Важно быстро.
* Наивные вопросы из зала — а как бы сделать откат все-таки…
* Техника — <tt>diff</tt>, <tt>ant</tt>, <tt>hudson</tt>/<tt>teamcity</tt>. Тесты — легкие постоянно, тяжелые ночью. И авторассылка результатов тестов.
* Деревня для автотестов (синтетические данные).