Персональные инструменты
 

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

Материал из CustisWiki

Версия от 15:08, 3 июня 2011; StasFomin (обсуждение | вклад)

Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Перейти к: навигация, поиск

Аннотация

Докладчик
Владимир Бахов

Непрерывная интеграция — это высокотехнологический инструмент, неотъемлемая часть качественной бездефектной машины по производству ПО. Средства и методология непрерывной интеграции программных приложений хорошо развиты на сегодняшний день. Однако разработка сложных баз данных существенно отличается от разработки приложений. Зачастую неприменимы классические методы непрерывной интеграции: использования системы контроля версий, автоматической сборки скриптов наката релиза, системы автоматизированного тестирования.

Тем не менее, agile парадигмы о раннем, постоянном и автоматизированном тестировании качества сборки могут найти свое полноправное место и в разработке баз данных. Презентация посвящена методологическим и практическим особенностям построения CI для Oracle базы данных.

Видео

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/22486507?byline=0&portrait=0" width="720" height="405" frameborder="0"></iframe>


Для этого доклада нужен подкаст (аудиозапись)?

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).

Презентация

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

Примечания и отзывы

Докладчик
Владимир Бахов
Компания
AT-Consulting

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

Рациональным зерном является то, что

  • нужно запретить ручные правки в базе данных в процессе разработки, изменяя только скрипты;
  • в той части разработки, которая касается БД, тоже использовать Continuous integration

Что не понравилось в докладе:

  1. Используемые термины «накат изменений», «продуктивная среда», «продуктив».
  2. Первоначальная структура таблиц в скриптах и данные не хранится, восстанавливается из первоначального дампа.
  3. Очень перегруженные слайды доклада.

Что понравилось:

  1. Идея Continuous integration к БД.
  2. Обязательное использование библиотеки для unit-тестирования PL-SQL-кода (используют utPLSQL)
  3. Использование средств мониторинга успешности/неуспешности очередной сборки.
  4. Автогенерация скрипта изменений в БД.

Неоднозначный, но полезный доклад для расширения кругозора.

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

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

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

Заметки.

  • Началось все как-то примитивно, когда был просто ручная сборка скриптов и накат, нет версионности БД, несоответствие тестовой и боевой по производительности и т. п.
  • И вообще скриптовый build-инженер ушел в отпуск — жопа
  • Я еще мяч между dba и разработчиков. Да еще когда поставка на площадку, где накатывают другие люди.
  • Якобы все решает непрерывная интеграция. Я: На самом деле — совсем не все, то о чем он говорит — это просто наличие тестовых площадках, а непрерывная интеграция — про другое.
Стас Фомин:Собственно это я говорил автору еще на этапе ревью. И впечатлил оного — после доклада он подходил ко мне, чтобы я посоветовал ему гуру непрерывной интерграции — я послал его к вам и Игорю Беспальчуку (сам был в полном мыле, общатся не мог), не знаю, дошел ли он до наших.
  • Что есть БД — в ней много данных, надо накатывать изменения, делать миграцию и прочее.
  • В общем, с БД сложнее, чем с веб-приложениями.
  • Особенно откат на предыдущую версию. Например, drop table.
  • Есть проблемы с продуктами, поддерживающими CI…
  • 15 минут внедрения. потом решение — да, это можно.
  • Что надо: svn + UTPLsql (сейчас у Oracle в sqldev что-то вышло)
  • Задача первая — все менять скриптами.
  • Для начала — надо снять текущий слепок кодов проекта prod (по умолчанию исходных кодов нет). Снимают в директории по типам объектов. И именуют с цифрами для правильной сортировке.
  • Есть trunc. А дальше — diff между trunc и prod. И накатываем. Продуктив один (хотя там можно по версиям, наверное). Специально добавляют какие-то скрипты и пишут их вручную. По вопросам — надеялись и это автоматом сделать.
  • Урезанная продуктивная база для синтетического тестирования.
  • Важны функциональные синтетические тесты.
  • Поднятие локальной базы — для всех разработчиков. Важно быстро.
  • Наивные вопросы из зала — а как бы сделать откат все-таки…
  • Техника — diff, ant, hudson/teamcity. Тесты — легкие постоянно, тяжелые ночью. И авторассылка результатов тестов.
  • Деревня для автотестов (синтетические данные).


Призыв к зрителям!

Мы призываем всех зрителей видеозаписей докладов давать хоть какой-нибудь, желательно конструктивный feedback.

Где? — неважно. В блогах, в форумах, в комментах — пофиг, лишь бы можно было найти, например, поиском по блогам, по ключевому слову «AgileDays» (ну и/или по названию доклада).

Что-то побольше твиттер-вскрика, хотя бы пару абзацев. Да, иногда краткая характеристика бывает достаточной («маркетинговый булшит», «унылый самопиар» — обычно в адрес «спонсорских докладов»), но это очень, очень редко, а так хочется прочитать что-то большее, чем «сижу на XXX, говорят о YYY».

Что писать? Что хорошо, что плохо («плохо» неудачное слово, скажем, «неправильно на ваш взгляд»), как вы поняли то, что рассказано, как это спроецировалось конкретно на вас — все это фантастически важно и полезно:

  • Другим потенциальным зрителям (смотреть/не смотреть, «правильно ли я понял»).
  • И докладчикам:
    • «Правильно ли меня поняли»,
    • «Что я делал правильно, а что улучшить»
    • Даже критический отзыв лучше, чем никакого!
    • Плюс — это мотивация, это награда за немалый труд многие готовятся долго, раскрывают свой опыт, старательно делают слайды, репетируют выступление — и ради чего? двадцать минут театра перед парой десятков зритетелей и все?
  • Организаторам конференций (этой и других) — они внимательно следят за отзывами, и пытаются понять, кого имеет смысл звать («рубит фишку и жжет!»), а к кому отнестись скептически, и если брать, то, например, «прокачать в части выступлений» — мы, например, старались это делать, итеративно рецензировали слайды, рассылали подборку литературы о правильных слайдах и искусстве выступлений.
  • Безотносительно лично докладчиков — важно понять, исчерпала себя тема или для народа еще остаются откровениями то, что для более пресыщенных инфопотоками людей (а организаторы обычно такие) уже выглядит как «аццкий боян». Ну и вообще — что еще интересно, и что было бы интересно услышать-увидеть-пообщаться на тему о…
  • Ну и кстати, мне тоже важно — вообще имел ли смысл весь этот сыр-бор с сьемкой, видеомонтажем и обработкой и публикацией (это, вообще-то дорогая работа, расценки профессионалов в этой области весьма недетские, при том, что до этого уровня монтажа им, как правило очень далеко), или кроме участников конференции эти темы никому не интересны. Может есть какие-то косяки в видео? или предложения как сделать лучше? — связывайтесь со мной, возможно это можно будет исправить (или хотя бы вырезать). Это кстати относится и к докладчикам — если есть какие-то позорные неудачные моменты, или что-то не нравится — это можно убрать.


Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».


Репликация: База Знаний «Заказных Информ Систем» → «Непрерывная интеграция при разработке баз данных (Владимир Бахов, AgileDays-2011)»