Изменения определены в xml — мерзость какая, xml совсем не дружелюбный для такого (ИМХО).
Проще уже было бы, если бы были plain-text-sql файлы.
Миграций может быть очень много и размеры их могут быть очень большими (есть реальный опыт).
Такие штуки лучше встраивать в приложение, а не в сборку: сервис поднялся и, если позволено, обновил базу.
Задача:
Имеется продукт, основная ветка.
Команда делает 5-6 вещей (баг фиксы, изменения поведения, новые фичи и т.д.) одновременно, тестят их по готовности и вместе (проверить финальную интеграцию).
На момент релиза (сроки которые могут, внезапно (с), меняться) нужно выпустить несколько фич:
какие-то ещё не доделаны, 5 готовы, но выпустить надо только 4, от последней отказались. Ещё 2 перенесли на следующий релиз.
Вопрос: как это сделать с SVN, чтобы разработчики не заплакали кровавыми слезами?
Git всегда проверяет целостность. commit id берётся из контрольных сумм объектов. К тому же, файлы в репозиторий добавляются не из рабочей копии, как можно сначала подумать, а из индекса. а эта область лежит целиком в папке .git. Эта папка в свою очередь является «собственностью» git-a. И если кто-то что-то там в ней будет менять вслед за git — ничего удивительного тут нет.
Git пишет «карта», программа перетирает «В*ЧНОСТЬ».
Естественно, git задаст резонный вопрос:
«Где карта, Билли!»
Кстати, вброшу ка я: jgit некорректно работает с git и там много багов. Это скорее всего основная проблема.
Сам лично словил тонну глюков, когда использова maven-jgitflow-plugin. Обновление jgit частично помогло. Было это 3 месяца назад. Как сейчас обстоят дела я не знаю.
Пользуюсь Chef.
По началу казалось, что разработка инфраструктуры с chef — это не просто долго, это вечность!
Когда побольше разобрался в нём — дела пошли куда быстрее.
Хотя, от этого он не перестаёт быть сложным и медленным (в плане разработки).
Однако, в защиту Chef могу сказать, что сообщество очень быстро адаптируется и меняется в лучшую сторону.
Появляется всё больше удобных инструментов, которые существенно ускоряют процесс разработки. Потихоньку вырабатываются best practice/chef patterns для работы с cookbooks. Качество community cookbooks (они же library cookbooks) быстро растёт. К моменту выхода chef 12 картина должна существенно улучшиться.
Мой «джентльменский набор» сейчас такой: Chef Zero, Test-Kitchen, Berkshelf, Docker (test kitchen driver for docker), chefspec, bats, serverspec.
Основная причина по которой остаюсь на Chef это orchestration: работа с кластерами, зависимости между серверами.
Конечно, есть тот же etcd который может частично решить проблему.
А вообще, Docker мне очень понравился, отличная идея, отличный проект. Подумываю над тем, чтобы серверами-болванками управлять через Chef, раскатывать проект через Docker (есть cookbook: github.com/bflad/chef-docker), настраивать опять же Chef-ом или каким-нибудь другим сервисом.
Очень негативно восприняли такие возможности.
Мол, ничего хорошего от этого ждать не приходится. Ща поменяет лишний курсор строчку где не надо и на проде всё ляжет…
Вообще, я даже смирился, пусть делают как хотят/как им удобнее.
Лично я испытываю настоящее наслаждение, когда немного подучил эту фишку и уже активно ею пользуюсь.
Что-то в скрипте/коде поменять можно в 5-10 нажатий на клаве, а не Find&Replace->Set Regexp Mode-> [write regexp -> replace one -> ctrl+z -> fix regexp].many-times -> replace-all with regexp.
По каким параметрам?
Вы сможете меня убедить перейти на hg?
Правда, без подтекста и намёка на холивар спрашиваю. Сколько раз хотел услышать внятные комментарии, где бы на пальцах объяснили.
И тот, и другой — хороши. Если у вас есть серьёзный опыт и там, и там — расскажите про «hg лучше git»
Я так делал 2 (3, 5, 7) лет назад и по-другому не буду. Нафиг мне это всё нужно.
Профилировщики/Сонары/Анализаторы — это мне не нужно, я и так знаю, что я пишу
От опытного (10+ лет) ресурс/проджект менджера/тех. лида: программист не должен знать/уметь работать с системами контроля версий, он должен уметь писать код. Кнопку нажал и готово. Зачем тратить время на изучение этих систем, только база: как сделать commit/push/branch
Как следствие предыдущего пункта: git. Я уже всё запушил, а потом закоммитал, забирайте.
Никак не могу переубедить, заставить что-то выучить.
Увидели статью про multi cursors — «это хрень какая-то. На нашем проекте нельзя, запретить! А то ща что-нибудь наделают. Я бы такому девелоперу… бла бла бла...»
Тут вы по сути описали волшебную кнопку, которую надо нажать. А речь шла скорее про то, на сколько тяжело эту самую кнопку сделать. с таким же успехом я бы мог ответить на свой вопрос так:
Лично пока с puppet не работал, но мой друг столкнулся с проблемой организации циклов, которые DSL не поддерживает (во всяком случае я такое от него услышал год назад). И ему пришлось сильно постараться.
Всё-таки puppet основан на DSL, который явно ограничен по сравнению с plain ruby. А сам по себе язык ruby имеет довольно приятный синтаксис.
Но, давайте не будем сравнивать тёплое с мягким, а остановимся на более конкретных вещах.
В последнее время, что в сообществе Chef, что в Puppet (да и других) очень часто тиражируют бесполезные «красивые» примеры применения в стиле «как поставить apache + wordpress» или «добавить юзера в mysql».
Очень не хватает реальных задач, который имеют свои особенности и не являются такими тривиальными. Вот тут-то и начинается самое интересное.
Вот, например, какую мне пришлось решить:
Установить и настроить mongodb cluster с возможностью объединения нод в реплики (replicaset) и добавлением этих реплик или просто нод как shard в общий кластер. При этом нужно уметь:
* держать на одном сервере несколько демонов: config db, mongo router и какой-нибудь mongod инстанс; или MongoDB Arbiter для ReplicaSet1 вместе с Mongod для ReplicaSet2
* Добавлять на лету ноды в реплику, реплики/шарды в кластер
* Иметь возможность дополнительно настраивать реплики (rs.conf())
Вот такая вот интересная задачка. Можно подумать как её решить с использованием Chef, а как с использованием Puppet.
Как только задачи перестаёт быть сферической в вакууме, сразу станет понятнее, что лучше использовать.
В интернете можно найти несколько cookbooks для MongoDB, но есть впечатление, что авторы не читали документацию вообще. И сколько бы там всего заявлено не было, хорошо, если этот cookbook сможет поднять примитивный кластер или реплику.
Поэтому сначала это и делается на dev (тоесть локальной машине)
Не всегда можно воспроизвести всё на локальной машине. Более того, может быть чёткое требование: на PROD1 делай так, а на PROD2 по-другому.
А так, да — сам пытаюсь всё локально проверять и тестить перед отправкой. И все версии зафиксированы строго. Сначала думал, что будет очень тяжело поддерживать все версии. На практике оказалось это очень редкое занятие и отнимает буквально пару минут. Зато не раз спало в сложных ситуациях.
Вот ещё никак руки не дойдут потыкать палочкой vagrant-lxc для поднятия более сложных вещей с меньшими ресурсами…
Не соглашусь с вами. Точнее даже не так: у вас конкретный подход, когда chef-client выключен.
Тогда всё просто: речь идёт о явном запуске и переконфигурации. В большинстве случаев chef-client постоянно крутится на сервере и следит за состоянием серверов. Особенно в клауде.
Добавились 3-4 бэканда — балансер уже «знает» об этом и перенастраивается (без явного вызова chef-client). Именно в таких случаях опасно менять глобальные роли/рецепты и т.д.
Если у вас по 10 серверов на окружение и вы толкнули роль, вероятно, через 3-5 минут 2-3 сервера уже будут перенастроены. Подход выше позволяет контролировать этот процесс и тестировать сначала на отдельных окружениях.
Такая же ситуация и с рецептами: обновил cookbook и везде, где его версия строго не была зафиксирована, он обновится (и что-нибудь сломает).
Кстати, в вашем же случае отключение chef-client как демон — не спасение! Это просто надежда, что «вот пока я буду разрабатывать/тетсить/исправлять баг» никто не додумается запустить chef-client на проде.
PS. В примере выше через knife ssh запускалась команда tail, а не chef-client. Сам по себе knife ssh не запускает реконфигурацию.
jsirex.livejournal.com/27049.html
Требует силы как настоящий 10-минутный спарринг на полную силу.
Вот, любимый мной, Dragonforce (играю, правда, не я; мне пока скилов не хватает) 200 bpm. 800 ударов в минуту.
Это ооочень сложно. А на 99% вообще нереально.
Проще уже было бы, если бы были plain-text-sql файлы.
Миграций может быть очень много и размеры их могут быть очень большими (есть реальный опыт).
Такие штуки лучше встраивать в приложение, а не в сборку: сервис поднялся и, если позволено, обновил базу.
Рекомендую посмотреть на dbmaintain.org/overview.html
Я его заливал на github, добавлял фазу preprocessing:
github.com/jsirex/dbmaintain/tree/preproccessing
Имеется продукт, основная ветка.
Команда делает 5-6 вещей (баг фиксы, изменения поведения, новые фичи и т.д.) одновременно, тестят их по готовности и вместе (проверить финальную интеграцию).
На момент релиза (сроки которые могут, внезапно (с), меняться) нужно выпустить несколько фич:
какие-то ещё не доделаны, 5 готовы, но выпустить надо только 4, от последней отказались. Ещё 2 перенесли на следующий релиз.
Вопрос: как это сделать с SVN, чтобы разработчики не заплакали кровавыми слезами?
Git пишет «карта», программа перетирает «В*ЧНОСТЬ».
Естественно, git задаст резонный вопрос:
«Где карта, Билли!»
Кстати, вброшу ка я: jgit некорректно работает с git и там много багов. Это скорее всего основная проблема.
Сам лично словил тонну глюков, когда использова maven-jgitflow-plugin. Обновление jgit частично помогло. Было это 3 месяца назад. Как сейчас обстоят дела я не знаю.
По началу казалось, что разработка инфраструктуры с chef — это не просто долго, это вечность!
Когда побольше разобрался в нём — дела пошли куда быстрее.
Хотя, от этого он не перестаёт быть сложным и медленным (в плане разработки).
Однако, в защиту Chef могу сказать, что сообщество очень быстро адаптируется и меняется в лучшую сторону.
Появляется всё больше удобных инструментов, которые существенно ускоряют процесс разработки. Потихоньку вырабатываются best practice/chef patterns для работы с cookbooks. Качество community cookbooks (они же library cookbooks) быстро растёт. К моменту выхода chef 12 картина должна существенно улучшиться.
Мой «джентльменский набор» сейчас такой: Chef Zero, Test-Kitchen, Berkshelf, Docker (test kitchen driver for docker), chefspec, bats, serverspec.
Основная причина по которой остаюсь на Chef это orchestration: работа с кластерами, зависимости между серверами.
Конечно, есть тот же etcd который может частично решить проблему.
А вообще, Docker мне очень понравился, отличная идея, отличный проект. Подумываю над тем, чтобы серверами-болванками управлять через Chef, раскатывать проект через Docker (есть cookbook: github.com/bflad/chef-docker), настраивать опять же Chef-ом или каким-нибудь другим сервисом.
Очень негативно восприняли такие возможности.
Мол, ничего хорошего от этого ждать не приходится. Ща поменяет лишний курсор строчку где не надо и на проде всё ляжет…
Вообще, я даже смирился, пусть делают как хотят/как им удобнее.
Лично я испытываю настоящее наслаждение, когда немного подучил эту фишку и уже активно ею пользуюсь.
Что-то в скрипте/коде поменять можно в 5-10 нажатий на клаве, а не Find&Replace->Set Regexp Mode-> [write regexp -> replace one -> ctrl+z -> fix regexp].many-times -> replace-all with regexp.
Вы сможете меня убедить перейти на hg?
Правда, без подтекста и намёка на холивар спрашиваю. Сколько раз хотел услышать внятные комментарии, где бы на пальцах объяснили.
И тот, и другой — хороши. Если у вас есть серьёзный опыт и там, и там — расскажите про «hg лучше git»
Никак не могу переубедить, заставить что-то выучить.
Увидели статью про multi cursors — «это хрень какая-то. На нашем проекте нельзя, запретить! А то ща что-нибудь наделают. Я бы такому девелоперу… бла бла бла...»
Дополню этот вопрос:
Как вы добавите шард в кластер, даже если кол-во нод не будет меняться? Как вы настроите реплику?
Переделанная документация шефа сейчас ОЧЕНЬ качественная.
Огромное уважение разработчикам.
Всё-таки puppet основан на DSL, который явно ограничен по сравнению с plain ruby. А сам по себе язык ruby имеет довольно приятный синтаксис.
Но, давайте не будем сравнивать тёплое с мягким, а остановимся на более конкретных вещах.
В последнее время, что в сообществе Chef, что в Puppet (да и других) очень часто тиражируют бесполезные «красивые» примеры применения в стиле «как поставить apache + wordpress» или «добавить юзера в mysql».
Очень не хватает реальных задач, который имеют свои особенности и не являются такими тривиальными. Вот тут-то и начинается самое интересное.
Вот, например, какую мне пришлось решить:
Установить и настроить mongodb cluster с возможностью объединения нод в реплики (replicaset) и добавлением этих реплик или просто нод как shard в общий кластер. При этом нужно уметь:
* держать на одном сервере несколько демонов: config db, mongo router и какой-нибудь mongod инстанс; или MongoDB Arbiter для ReplicaSet1 вместе с Mongod для ReplicaSet2
* Добавлять на лету ноды в реплику, реплики/шарды в кластер
* Иметь возможность дополнительно настраивать реплики (rs.conf())
Вот такая вот интересная задачка. Можно подумать как её решить с использованием Chef, а как с использованием Puppet.
Как только задачи перестаёт быть сферической в вакууме, сразу станет понятнее, что лучше использовать.
В интернете можно найти несколько cookbooks для MongoDB, но есть впечатление, что авторы не читали документацию вообще. И сколько бы там всего заявлено не было, хорошо, если этот cookbook сможет поднять примитивный кластер или реплику.
Именно это и имел в виду, когда говорил:
Не всегда можно воспроизвести всё на локальной машине. Более того, может быть чёткое требование: на PROD1 делай так, а на PROD2 по-другому.
А так, да — сам пытаюсь всё локально проверять и тестить перед отправкой. И все версии зафиксированы строго. Сначала думал, что будет очень тяжело поддерживать все версии. На практике оказалось это очень редкое занятие и отнимает буквально пару минут. Зато не раз спало в сложных ситуациях.
Вот ещё никак руки не дойдут потыкать палочкой vagrant-lxc для поднятия более сложных вещей с меньшими ресурсами…
Минус: дополнительные расходы на содержание одного сервера.
Плюсы: всё достаточно изолировано, можно ограничивать права разработчиков и не пускать их на прод, оставляя полные права на dev/qa/staging.
Очень хорошо, что вы об этом упомянули.
Тогда всё просто: речь идёт о явном запуске и переконфигурации. В большинстве случаев chef-client постоянно крутится на сервере и следит за состоянием серверов. Особенно в клауде.
Добавились 3-4 бэканда — балансер уже «знает» об этом и перенастраивается (без явного вызова chef-client). Именно в таких случаях опасно менять глобальные роли/рецепты и т.д.
Если у вас по 10 серверов на окружение и вы толкнули роль, вероятно, через 3-5 минут 2-3 сервера уже будут перенастроены. Подход выше позволяет контролировать этот процесс и тестировать сначала на отдельных окружениях.
Такая же ситуация и с рецептами: обновил cookbook и везде, где его версия строго не была зафиксирована, он обновится (и что-нибудь сломает).
Кстати, в вашем же случае отключение chef-client как демон — не спасение! Это просто надежда, что «вот пока я буду разрабатывать/тетсить/исправлять баг» никто не додумается запустить chef-client на проде.
PS. В примере выше через knife ssh запускалась команда tail, а не chef-client. Сам по себе knife ssh не запускает реконфигурацию.