Веб-приложение процесс разработки - управление версиями, отслеживание ошибок, поблочное тестирование, развертывание

Метод, который вы используете, CONCAT() LIKE ? обязан выполнить сканирование таблицы. Так что он будет медленнее прямо пропорционально размеру вашего стола.

Если вам нужно выполнить полнотекстовый поиск по нескольким столбцам и вы хотите, чтобы он работал эффективно, вам следует узнать о функциях полнотекстового поиска MySQL .

Я провел презентацию, сравнивая запросы типа LIKE '%pattern%' старой школы и запросы с использованием полнотекстовых индексов. Это зависит от того, сколько у вас данных, но полнотекстовые индексы могут сделать ваши запросы в сотни или тысячи раз быстрее , чем выполнять поиск, как вы это делаете.

См. Мою презентацию: Развертывание полнотекстового поиска .

5
задан underskor 19 March 2009 в 10:47
поделиться

2 ответа

Очень примерно:

  1. Создайте репозиторий в SVN
  2. Проверка локальной рабочей копии к среде разработчика
  3. Обновление/фиксация часто изменяется
  4. Развернитесь для подготовки от соединительной линии SVN, использующей пользовательский, развертывают сценарий
  5. Тесты QA на этапе, сообщает об ошибках у Богомола
  6. Разработчики исправляют ошибки, метка, как разрешено
  7. Повторно развернитесь на этапе
  8. QA тестирует ошибки, завершения, если зафиксировано
  9. QA закончен, сделайте регрессионное тестирование
  10. Развернитесь к производству, использующему пользовательский, развертывают сценарий
  11. Действительно немного танцевать

Мы также создаем ответвления для будущих версий или функций. Они в конечном счете объединяются в соединительную линию.

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

1
ответ дан 15 December 2019 в 01:11
поделиться
  1. Создайте/контроль ГЛАВНУЮ версию ("основное ответвление")
  2. Разработайте код и синхронизацию с основным ответвлением - по крайней мере, ежедневно
  3. После того, как разработка сделана, запишите и выполните модульные тесты
  4. Пройдите обзор кода и подвергните код/изменения основному ответвлению
  5. Позвольте непрерывному разработчику выполнить все модульные тесты и систему/интеграционные тесты на основном ответвлении
  6. Когда готовый, изменения избирательного подхода и интегрируют их к ответвлению QA
  7. Выполните тестирование системы и интеграционные тесты, исправьте ошибки, о которых сообщают или откатывайте по мере необходимости; это повторяет шаги 4-7
  8. После выхода QA интегрируйте изменение QA для выпуска ответвления
  9. Выполненные модульные тесты, система/интеграционные тесты на ответвлении выпуска
  10. Развернитесь к производству и запустите тесты исправности.

Сервер подготовки является копией Вашей продуктивной среды, которая максимально актуальна. На моем текущем проекте мы можем сохранить каждый выпуск независимым друг от друга, таким образом, наш "сервер подготовки" является нашим рабочим сервером, к которому просто получают доступ от другого URL.

Примечания и discreprencies:

Все шаги имеют некоторое изменение в зависимости от размера Вашего проекта. Чем больше Ваш проект, тем лучше преимущество от избирательного подхода к выбору и разделения среды. В меньших проектах они могут просто быть приемниками времени и часто игнорируются или обходятся.

Для разъяснения существует стек Development, стек QA и стек Staging. В зависимости от Вашего размера проекта QA мог бы подготавливать, Производство могло бы подготавливать, или некоторая комбинация этого. Разделение Dev и стопок QA является самым важным.

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

В проекте маленьком среднего размера, там может или может не быть ответвление выпуска; это зависит от частоты изменения кода. Кроме того, в зависимости от частоты изменения кода и размера Вашего проекта, можно интегрировать полное ответвление QA к ответвлению Выпуска или избирательно подойти к выбору определенных изменений для интеграции к ответвлению выпуска.

FWIW, я нашел, "что сценарии миграции" имеют мало ценности. Они всегда - одноразовый сценарий с небольшим повторным использованием и делают откаты болью в заднице. Его намного более легкое, я требовал бы лучше, иметь назад совместимое приложение. После нескольких выпусков (когда откат является смехотворным), очистка данных должна быть сделана при необходимости.

2
ответ дан 15 December 2019 в 01:11
поделиться
Другие вопросы по тегам:

Похожие вопросы: