Используем 2й и 4й.
2й вариант для таблиц, активно учавствующих в бизнес логике, где нельзя держать несколько одинаковых записей рядом.
4й вариант больше для контента (новости, статические страницы, статьи).
Видел еще реализации с несколькими таблицами (news_ru, news_en)
Начинали с gettext, но потом ушли все же в базу (больше тысячи ключей).
Получается, что после изменений в php коде вы проверяете скрипты puppet, какой смысл? Не лучше ли будет проверять сборку «кластера» после ченжей в puppet скриптах? Другой вопрос, не лежат ли puppet скрипты вместе с общим кодом…
ИМХО. Для каждого пуша в фича ветки — запускать smoke тесты. Библиотеки вынести отдельно.
После мержа в beta запускать «итеративную миграцию»(я так понимаю это обычный апдейт в репосе), чтобы на интеграционном хосте уже был результат и QA могли работать. Деплой с нуля, UI тестинг и функциональщина — это 3 отдельных задачи для дженкинса и они могут выполняться параллельно. Советую использовать плагин для Jenkins — Build Pipeline, в вашем случае очень пригодится
Ну вот все сложные и «проблемные» схемы можно дергать курлом.
С моделями у нас когда-то тоже были такие проверки, но они подойдут только для несложных CRUD операций. Когда таких бесполезных тестов накопилось большое количество — от них отказались и начали мокать все обращения к бд, иначе скорость хромает. А что если будут сложные выборки на 2-3 таблицы, как их проверяете?
А можете чуть подробнее рассказать о шотах?
Если они не изолированы друг от друга, т.е используют одинаковые подключения к базам, то, получается, они могут влиять друг на друга(общий кеш, поменялась структура данных уходящих в очередь и тд)?
В функциональных тестах какая база используется? Та же, что и в девелоперском окружении? Если да, то при постоянном запуске(100 задач * 18000 тестов) она будет забиваться различными данными. Или все же используются для этого отдельные снапшоты/фикстуры БД?
7. Если Stage работает с продакшен базой, как происходит тестирование при изменении схемы(мажор фича, к примеру)? Используются ли инструменты для миграций?
8. Я так понял ветвитесь только в один уровень, а если нужно работать группой разработчиков над одной фичей и каждый будет ветвится от этой фича-ветки?
9. Были ли случаи, когда на продакшен ушла очередная фича, но через несколько релизов оказалось, что её нужно откатить. Как происходит этот процес?
А представляете, что это будет за простыня кода на классическом jQuery, если в организованом виде на Backbone вьюх больше 50? Todomvc Backbone Requirejs Example Todomvc jQuery Example
Кода, как видно, больше, но читаемость, расширяемость и модульность в разы лучше, как по мне.
В книге описывается хорошо сам принцип TDD на примерах, а в качестве тестового фреймворка используют xUnit, что не вызывает сложности в проецировании на NUnit
Теги в стабильной ветке нужны для того, чтобы при деплое указывать конкретную версию релиза, т.к у нас команды разработчиков и тестеров работают независимо друг от друга и на момент пока тестеры проверят одну версию релиза, разработчики могут выпустить следующую.
Continuous Delivery — конвеер доставки приложения в конечную точку, состоящий из нескольких шагов: сборка проекта, выпуск релиза, тестирование командой QA, деплой на сервера. Шаги могут варьироваться.
Continuous Integration — один из шагов, который выполняет регулярные сборки в целях мониторинга состояния приложения на стадии разработки.
Спасибо за критику, в следующий раз постараюсь более подробно описывать.
Цель статьи — поделиться наработками в направлении CD, кому-то она будет полезной, а кто-то укажет на ошибки и возможные проблемы, либо предложит лучший вариант.
2й вариант для таблиц, активно учавствующих в бизнес логике, где нельзя держать несколько одинаковых записей рядом.
4й вариант больше для контента (новости, статические страницы, статьи).
Видел еще реализации с несколькими таблицами (news_ru, news_en)
Начинали с gettext, но потом ушли все же в базу (больше тысячи ключей).
ИМХО. Для каждого пуша в фича ветки — запускать smoke тесты. Библиотеки вынести отдельно.
После мержа в beta запускать «итеративную миграцию»(я так понимаю это обычный апдейт в репосе), чтобы на интеграционном хосте уже был результат и QA могли работать. Деплой с нуля, UI тестинг и функциональщина — это 3 отдельных задачи для дженкинса и они могут выполняться параллельно. Советую использовать плагин для Jenkins — Build Pipeline, в вашем случае очень пригодится
Зачем каждый коммит? Все что в dev/master ветку пушится.
UPD 30 минут билд — что в него входит?
С моделями у нас когда-то тоже были такие проверки, но они подойдут только для несложных CRUD операций. Когда таких бесполезных тестов накопилось большое количество — от них отказались и начали мокать все обращения к бд, иначе скорость хромает. А что если будут сложные выборки на 2-3 таблицы, как их проверяете?
Поднимается локально у тестера на машине или на сервере?
Для проверки Javascript и CSS валидности советую использовать Gruntjs с jshint и csslint.
Если они не изолированы друг от друга, т.е используют одинаковые подключения к базам, то, получается, они могут влиять друг на друга(общий кеш, поменялась структура данных уходящих в очередь и тд)?
В функциональных тестах какая база используется? Та же, что и в девелоперском окружении? Если да, то при постоянном запуске(100 задач * 18000 тестов) она будет забиваться различными данными. Или все же используются для этого отдельные снапшоты/фикстуры БД?
7. Если Stage работает с продакшен базой, как происходит тестирование при изменении схемы(мажор фича, к примеру)? Используются ли инструменты для миграций?
8. Я так понял ветвитесь только в один уровень, а если нужно работать группой разработчиков над одной фичей и каждый будет ветвится от этой фича-ветки?
9. Были ли случаи, когда на продакшен ушла очередная фича, но через несколько релизов оказалось, что её нужно откатить. Как происходит этот процес?
UPD промазал, это для коммента 6287717
Todomvc Backbone Requirejs Example
Todomvc jQuery Example
Кода, как видно, больше, но читаемость, расширяемость и модульность в разы лучше, как по мне.
можно использовать JSON Action Helper и тогда код сократится до:
http://wiki.agiledev.ru/doku.php?id=tdd:tdd_into_command тут хорошо описано
Continuous Integration — один из шагов, который выполняет регулярные сборки в целях мониторинга состояния приложения на стадии разработки.
Цель статьи — поделиться наработками в направлении CD, кому-то она будет полезной, а кто-то укажет на ошибки и возможные проблемы, либо предложит лучший вариант.