Ох, гости и темы безусловно интересны и круты, но блин, чуваки такой командой за 5−7 лет так и не смогли научиться звук нормально делать. Некоторые выпуски просто невозможно слушать :(
Дополню пару слов про третий вариант.
Мы используем https://github.com/db-migrate/node-db-migrate. Это аналог упомянутых инструментов на node.js. Умеет работать из коробки с mysql, postgresql, sqlite3 и mongodb.
Из плюсов:
Миграции можно писать как в js файлах используя ORM, так и в sql файлах
Есть scopes. То есть можно сделать несколько областей (dev, prod, test) и раскидать все миграции по соответствующим скоупам. Это дает возможность в каждом окружении запускать только необходимые миграции.
Из минусов:
нет pre- и post- скриптов. Но это не так критично.
В итоге, у нас работа построена следующим образом:
Мы активно используем хранимки, в коде приложений нет никаких запросов, только вызов хранимок.
Всё, что касается БД (и структуру и хранимки) разрабатывают программисты БД.
Каждый разработчик БД внося изменения в структуру базы, сам пишет небольшую миграцию (это довольно удобно, у db-migrate есть cli, который подготавливает для вас костяк, остаётся только заполнить 2 sql файла с миграцией вверх и вниз)
У нас 2 репозитория касательно БД: в одном живёт вся структура с нуля, статические справочники и все хранимки (по одному файлу на каждую сущность, будь то таблица, вьюха, хранимка и прочее), в другом живут только миграции.
Дальше у нас руками написан небольшой шелл скриптик, который подготавливает оба варианта развертывания базы для продакшн.
В итоге, если БД разворачивается с нуля — используется один скрипт, если же происходит обновление существующей БД, то накатываются только отсутствующие миграции и перенакатываются хранимки (ну просто потому что хранимки завязаны на структуру таблиц и нет смысла их держать в миграциях, а проще после накатить актуальные сразу, которые точно будут консистентны со структурой)
Вот это да!!! Охренеть! Прям открыли глаза на такие полезные инструменты! А то мужики-то все напрямую в бинарных файлах базы всё правят и не знают про /* Подставить любой из вышеперечисленных инструментов */
Простите, не сдержался :) Понедельник — день тяжелый!)
Народ, а покажите какие-нибудь реальные примеры API, описанных в RAML? И сгенерированные html'ки тоже было бы интересно увидеть.
И Самый главный вопрос: как поддерживать актуальность RAML-спецификаций и кода, который этот самый API реализует? Насколько я понял, надо только ручками после изменений апишки править RAML…
Кстати, про Tarantool, почему LUA, новый вид апп-серверов на базе nginx и tarantool'а и прочее мы общались с Костей Осиповым у меня в SDCast'е #20: sdcast.ksdaemon.ru/2015/03/sdcast-20
Честно говоря, вообще не согласен. У меня есть опыт перевода разного рода документации на маркдаун. При чем тех людей, которые никогда не были программистами. И они вполне себе освоились. И уж это точно проще, чем писать тэги html.
Если интересно, вот моя заметка по этому поводу: Вы все еще пишете ТЗ в Word? — Тогда мы идем к Вам!
Ай блиин! :) Извиняюсь! Попутал! Конечно же у SSE — всё отлично со звуком! Я имел в виду SE-Radio.NET (который software-engineering radio)
Ох, гости и темы безусловно интересны и круты, но блин, чуваки такой командой за 5−7 лет так и не смогли научиться звук нормально делать. Некоторые выпуски просто невозможно слушать :(
Хорошее интервью!
А для тех кто предпочитает аудио версию, или просто интересно, можно послушать SDCast #95 с Никитой, Иваном и Павлом.
Интересная статья, хоть и длинная %)
Кстати да! Первая аналогия, которая пришла в голову — была Deus Ex.
кажется, они просто разместили эту новость ради галочки «Размещено на хабре»… А ответы на вопросы заинтересованных… ну такое… :(
Дополню пару слов про третий вариант.
Мы используем https://github.com/db-migrate/node-db-migrate. Это аналог упомянутых инструментов на node.js. Умеет работать из коробки с mysql, postgresql, sqlite3 и mongodb.
Из плюсов:
Из минусов:
В итоге, у нас работа построена следующим образом:
Как-то так, если вкратце.
Простите, не сдержался :) Понедельник — день тяжелый!)
И Самый главный вопрос: как поддерживать актуальность RAML-спецификаций и кода, который этот самый API реализует? Насколько я понял, надо только ручками после изменений апишки править RAML…
А еще есть слайды с моего выступления на MoscowJS: «Пара слов про WAMP».
Вдруг кому-то пригодится.
Если интересно, вот моя заметка по этому поводу: Вы все еще пишете ТЗ в Word? — Тогда мы идем к Вам!