Под словами «полное тестирование фичи» я понимал не только автоматические, но и ручные тесты. Тестировать руками очень дорого и имеет смысл только код, максимально готовый к выезду на продакшен.
Видимо, я непонятно выразился в предыдущем комментарии. Транзакция стартует и заканчивается один раз. Остальные вызовы begin()/commit()/rollback() — фиктивные и увеличивают/уменьшают счетчик.
Удаление таблицы — действие, затрагивающее всю архитектуру. Как рефакторинг авторизации или acl. Чем позже такие изменения интегрируются с ветками тем сложнее интеграция. Не должно быть ситуации, что есть feature branches, которым нужна удаленная таблица — сразу после окончания рефакторинга нужно интегрироваться.
В разных обертках для работы с БД по разному, но принцип вроде везде одинаковый. Первый begin() открывает транзакцию, остальные — просто увеличивают счетчик. commit() счетчик уменьшает и при достижении нуля транзакция накатывается. rollback() тоже уменьшает счетчик, но при уменьшении счетчика до 0 — всегда будет откат транзакции, независимо от того что было в промежутках — commit или rollback().
Схема не идеальная, но поскольку обычно логика приложения без вложенных транзакций и нам важно просто сделать откат в tearDown() — вполне работает.
Расскажите, почему модульные тесты, обернутые в транзакции не будут работать на общей БД? Я вот только что открыл teamcity, и там, о чудо, они работают.
Вообще-то все зависит от того, что вы имеете ввиду под словами «тестовое окружение». Описанное мной — вполне является тестовым окружением. Некоторые системы крутятся на большом числе машин и к разработчикам на ноуты не влезают, чтобы там полноценно крутиться.
А еще нормальные разработчики внимательно читают то, на что отвечают и не домысливают значение фразы «в случае успеха»
Вполне возможно. В аргументированном споре рождается истина и происходит обмен опытом :)
По моему опыту откладывание интеграции — зло. Откладывание интеграции БД, где нет средств, вроде svn/git, которые ее упрощают — зло в квадрате.
Конечно, песочницы, где можно потестировать большие изменения в БД нужны. Но чем их меньше тем лучше.
Ок.
Сценарий 1 — Петя сломал всем сайт, починил за 5 минут, вся команда в курсе изменений и возможно выявила проблемы с переименованием, о которых забыл Петя.
Про тестирование большой фичи в отдельной ветке. Нельзя делать полное тестирование фичи, пока она не проинтегрирована в транк.
Сенарий 2 — Петя переименовал таблицу, сделал миграцию написал код и ушел домой.
Вася решил переименовать поле в этой таблице. Сделал миграцию и ушел домой, но перед уходом сказал Маше, что он поменял поле, т.к она тоже работает с авторизацией
Маша засиделась до поздна.
Утром Петя и Вася полчаса занимаются сексом с базой, кодом и файлами миграции. Маша смотрит на них с упреком т.к не понимает, что произошло.
Вы затронули кучу вопросов, которые пытаетесь решить с помощью миграций. И ни один из них не связан с БД. Попробую по порядку.
1. Стабильность и производительность БД (падает, медленная и тп). Если у вас падает БД — вы идете и чините ее (также, как если бы у вас упал продакшен). Если у вас падает или медленный интернет — вы переключаетесь на резерв или пинаете провайдера (также, как если бы вылетел канал у хостера). Не нужно решать организационные проблемы с помощью миграций.
2. Работа в полном offline. Очень неудачный способ удаленной работы, скорее исключение, чем правило (могу много написать, но это будет оффтопиком). Городить огород с миграциями вместо копирования структуры ради возможности иногда работать offline — личный выбор каждого. С учетом возможных проблем слияния я бы не стал.
3. История изменения базы в репозитории. Если у вас > 100 таблиц то без возможности сделать annotate на полном дампе, чтобы увидеть всю картину история (тем более в виде дельт) вам не поможет. Если у вас < 100 таблиц, то такая история вам не нужна. Упрощать коммуникацию между участниками команды при удаленной работе можно более простыми методами, нежели комментарии к дельтам миграции.
По секрету расскажу вам идеальную схему удаленной работы. Есть сервер разработки, на нем крутиться web и 1 инстанс бд. У каждого разработчика есть свой documet_root на сервере в домашней папке. Разработчики правят локальную копию и через scp/rsync закидывают правки на сервер и смотрят на результат на сервере. В случае успеха отправляют правки в репозиторий.
Работать можно из любого места где есть интернет и с любого устройства, где есть ssh. Все изменения конфигурации etc производятся один раз и влияют на всех.
Если разработчик своими изменениями сломал БД в момент правки, разве он не сломает ее делая все тоже самое через вашу систему миграций?
Если разные ветки — это разные проекты, которые больше никогда не сольются вместе — тут возражений нет. Если ветки нужно будет сливать — что будет, если за время расщепления в БД успеют поменяться имена таблиц и полей?
Наиболее частые изменения, как вы отметили в посте, инкрементальные — добавление таблиц и полей, иногда индексов. От того, что поля будут добавлены, но не будут использоваться в чужих ветках — большой беды не будет. Если же изменения необратимые (удаление полей/таблиц) — то чем раньше все об этом узнают (пусть даже получив fatal) — тем быстрее будут внесены нужные изменения в код.
Я размышляю в любых пределах.
Чем сложнее логика и больше людей работают над проектом тем больше вероятность конфликтов. Чем позже происходит синхронизация изменений — тем позже проблемы будут обнаружены и тем сложнее их исправлять. Если для исходного кода есть куча vcs, которые эти проблемы решают, то для БД таких инструментов нет.
Предложенная в посте схема отлично работает пока в правках БД нет конфликтов и вызывает кучу проблем когда они есть. Но, стоп, если нет конфликтов правок — почему не править на общем инстансе разработческой БД?
В этом случае конфликт хотя бы будет обнаружен в момент внесения изменения, а не когда Вася будет сливать свою ветку с транком и попытается накатить измения структуры базы.
Слушайте, мб я что-то не понимаю. Объясните, зачем каждому разработчику свой инстанс базы данных? Почему не работать на одной и с нее уже формировать скрипт миграции структуры БД на продакшене?
Про Zend заявление в стиле — не писал, но осуждаю. Про facebook и vkontakte — а еще они патчат ядро ОС, пишут свои веб-сервера и БД, давайте тоже начнем разработку с этого. Не надо сравнивать жопу с пальцем.
Стремиться к полному покрытию как к отдельной ценности — вредно. Обычно, 20% тестов решают 80% проблем, а остальные 80% тестов просто обеспечивают покрытие.
Не знаю как в nose, а в phpUnit есть интересный отчет — пофайловое покрытие, где в каждом файле зеленым подсвечиваются строки, которые выполнялись, а белым — которые нет. Этот отчет очень помогает находить ветви логики, которые забыли покрыть тестами, и низкое покрытие в пакете/файле — индикатор, что стоит взглянуть на этот отчет.
Безусловно покрыть сложную математику хорошими тестами сложно. Сами тесты будут полны магических чисел и допущений.
Но это совершенно не значит, что от них нужно отказываться. Вполне возможно писать smoke tests, прохождение которых не будет значить, что код работает правильно, но которые хотя бы покажут, что сломалось то, что работало ранее.
У меня был опыт разработки программ с математикой с тестами и без. С тестами значительно удобнее.
Разобрал ветвь алгоритма на бумаге, реализовал, забил в тест вход-выход с бумаги — и уже уверен, что хотя бы в одном случае код работает и не содержит дурацких ошибок.
Начал оптимизации, рефакторинг — прогнал тесты и сразу заметил — тут поползло, там сломалось. И заметил раньше, чем начал прогонять сложную модель, требующую длительных вычислений.
Да, во многих случаях smoke-тесты не заметят ошибки. Но ради тех ошибок, которые они выявят их стоит писать.
Вы правильно написали — тесты тут не панацея, но вполне годный инструмент, ускоряющий работу.
а по-поводу дружбы — почему не держать друзей в тех же шардах? ведь списки друзей всё равно дублируются для каждого пользователя — список друзей можно строить по тому же шарду, где и храниться профиль.
да, при этом не получится строить список за 5-м звеном. но, честно говоря, 5й круг не несет уже вообще никакого business value — там уже совсем незнакомые люди.
Удаление таблицы — действие, затрагивающее всю архитектуру. Как рефакторинг авторизации или acl. Чем позже такие изменения интегрируются с ветками тем сложнее интеграция. Не должно быть ситуации, что есть feature branches, которым нужна удаленная таблица — сразу после окончания рефакторинга нужно интегрироваться.
Схема не идеальная, но поскольку обычно логика приложения без вложенных транзакций и нам важно просто сделать откат в tearDown() — вполне работает.
А еще нормальные разработчики внимательно читают то, на что отвечают и не домысливают значение фразы «в случае успеха»
По моему опыту откладывание интеграции — зло. Откладывание интеграции БД, где нет средств, вроде svn/git, которые ее упрощают — зло в квадрате.
Конечно, песочницы, где можно потестировать большие изменения в БД нужны. Но чем их меньше тем лучше.
Сценарий 1 — Петя сломал всем сайт, починил за 5 минут, вся команда в курсе изменений и возможно выявила проблемы с переименованием, о которых забыл Петя.
Про тестирование большой фичи в отдельной ветке. Нельзя делать полное тестирование фичи, пока она не проинтегрирована в транк.
Сенарий 2 — Петя переименовал таблицу, сделал миграцию написал код и ушел домой.
Вася решил переименовать поле в этой таблице. Сделал миграцию и ушел домой, но перед уходом сказал Маше, что он поменял поле, т.к она тоже работает с авторизацией
Маша засиделась до поздна.
Утром Петя и Вася полчаса занимаются сексом с базой, кодом и файлами миграции. Маша смотрит на них с упреком т.к не понимает, что произошло.
1. Стабильность и производительность БД (падает, медленная и тп). Если у вас падает БД — вы идете и чините ее (также, как если бы у вас упал продакшен). Если у вас падает или медленный интернет — вы переключаетесь на резерв или пинаете провайдера (также, как если бы вылетел канал у хостера). Не нужно решать организационные проблемы с помощью миграций.
2. Работа в полном offline. Очень неудачный способ удаленной работы, скорее исключение, чем правило (могу много написать, но это будет оффтопиком). Городить огород с миграциями вместо копирования структуры ради возможности иногда работать offline — личный выбор каждого. С учетом возможных проблем слияния я бы не стал.
3. История изменения базы в репозитории. Если у вас > 100 таблиц то без возможности сделать annotate на полном дампе, чтобы увидеть всю картину история (тем более в виде дельт) вам не поможет. Если у вас < 100 таблиц, то такая история вам не нужна. Упрощать коммуникацию между участниками команды при удаленной работе можно более простыми методами, нежели комментарии к дельтам миграции.
По секрету расскажу вам идеальную схему удаленной работы. Есть сервер разработки, на нем крутиться web и 1 инстанс бд. У каждого разработчика есть свой documet_root на сервере в домашней папке. Разработчики правят локальную копию и через scp/rsync закидывают правки на сервер и смотрят на результат на сервере. В случае успеха отправляют правки в репозиторий.
Работать можно из любого места где есть интернет и с любого устройства, где есть ssh. Все изменения конфигурации etc производятся один раз и влияют на всех.
Если разработчик своими изменениями сломал БД в момент правки, разве он не сломает ее делая все тоже самое через вашу систему миграций?
Если разные ветки — это разные проекты, которые больше никогда не сольются вместе — тут возражений нет. Если ветки нужно будет сливать — что будет, если за время расщепления в БД успеют поменяться имена таблиц и полей?
Наиболее частые изменения, как вы отметили в посте, инкрементальные — добавление таблиц и полей, иногда индексов. От того, что поля будут добавлены, но не будут использоваться в чужих ветках — большой беды не будет. Если же изменения необратимые (удаление полей/таблиц) — то чем раньше все об этом узнают (пусть даже получив fatal) — тем быстрее будут внесены нужные изменения в код.
Чем сложнее логика и больше людей работают над проектом тем больше вероятность конфликтов. Чем позже происходит синхронизация изменений — тем позже проблемы будут обнаружены и тем сложнее их исправлять. Если для исходного кода есть куча vcs, которые эти проблемы решают, то для БД таких инструментов нет.
Предложенная в посте схема отлично работает пока в правках БД нет конфликтов и вызывает кучу проблем когда они есть. Но, стоп, если нет конфликтов правок — почему не править на общем инстансе разработческой БД?
В этом случае конфликт хотя бы будет обнаружен в момент внесения изменения, а не когда Вася будет сливать свою ветку с транком и попытается накатить измения структуры базы.
Не знаю как в nose, а в phpUnit есть интересный отчет — пофайловое покрытие, где в каждом файле зеленым подсвечиваются строки, которые выполнялись, а белым — которые нет. Этот отчет очень помогает находить ветви логики, которые забыли покрыть тестами, и низкое покрытие в пакете/файле — индикатор, что стоит взглянуть на этот отчет.
Но это совершенно не значит, что от них нужно отказываться. Вполне возможно писать smoke tests, прохождение которых не будет значить, что код работает правильно, но которые хотя бы покажут, что сломалось то, что работало ранее.
У меня был опыт разработки программ с математикой с тестами и без. С тестами значительно удобнее.
Разобрал ветвь алгоритма на бумаге, реализовал, забил в тест вход-выход с бумаги — и уже уверен, что хотя бы в одном случае код работает и не содержит дурацких ошибок.
Начал оптимизации, рефакторинг — прогнал тесты и сразу заметил — тут поползло, там сломалось. И заметил раньше, чем начал прогонять сложную модель, требующую длительных вычислений.
Да, во многих случаях smoke-тесты не заметят ошибки. Но ради тех ошибок, которые они выявят их стоит писать.
Вы правильно написали — тесты тут не панацея, но вполне годный инструмент, ускоряющий работу.
а по-поводу дружбы — почему не держать друзей в тех же шардах? ведь списки друзей всё равно дублируются для каждого пользователя — список друзей можно строить по тому же шарду, где и храниться профиль.
да, при этом не получится строить список за 5-м звеном. но, честно говоря, 5й круг не несет уже вообще никакого business value — там уже совсем незнакомые люди.