Процесс разработки веб-приложений - контроль версий, отслеживание ошибок, модульное тестирование, развертывание

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

Я новичок в этой области, поэтому мой примерный пример (читай: не использовал этот процесс) без сомнения, так сказать, не стоит - указать на недостатки, чтобы я мог учиться.

Eg.

  1. Создайте репозиторий проекта на локальном сервере SVN.
  2. Создайте пакетные сценарии / сценарии оболочки для сопоставлений DNS.
  3. Ознакомьтесь с проектом, начните работу над локальной рабочей копией.
  4. Развивайте функции в виде ветвей.
  5. Отслеживайте ошибки с помощью Mantis (ссылка фиксирует ошибки через интеграцию с SVN (не знаю, существует ли она)).
  6. Документируйте на ходу.
  7. Делайте QA на ветке.
  8. Слияние со стволом, когда оно стабильно.
  9. Модульное тестирование?
  10. Зафиксируйте в репозитории, когда функция будет реализована и стабильна.
  11. Скопируйте релизы в теги в репозитории. Например. / проект / теги / rel-123 /
  12. Используйте Phing для загрузки на промежуточный сервер. (Может ли кто-нибудь уточнить, какой именно промежуточный сервер используется помимо «тестирования»?)
  13. Используйте Phing для подготовки живого сайта к обновлению, настройки базы данных / развертывания и т. Д.

deployment web-applications bug-tracking process
person underskor    schedule 19.03.2009    source источник

Ответы (3)


arrow_upward
2
arrow_downward

  1. Создание / оформление HEAD-версии («основная ветвь»)
  2. Разрабатывайте код и синхронизируйте его с основной веткой - по крайней мере - ежедневно
  3. После завершения разработки напишите и запустите модульные тесты.
  4. Пройдите проверку кода и отправьте код / ​​изменения в основную ветку
  5. Разрешить непрерывному сборщику запускать все модульные тесты и системные / интеграционные тесты в основной ветке.
  6. Когда все будет готово, выберите ревизии и интегрируйте их в ветку QA.
  7. Запускать системные и интеграционные тесты, исправлять обнаруженные ошибки или откатывать при необходимости; это повторяет шаги 4-7
  8. После подписания QA интегрируйте изменения QA в ветку выпуска
  9. Запускать модульные тесты, системные / интеграционные тесты в ветке выпуска
  10. Разверните в производственной среде и запустите тесты работоспособности.

Промежуточный сервер - это максимально актуальная копия вашей производственной среды. В моем текущем проекте мы можем поддерживать независимость каждого выпуска друг от друга, поэтому наш «промежуточный сервер» - это наш производственный сервер, доступ к которому осуществляется с другого URL-адреса.

Примечания и неточности:

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

Чтобы уточнить, есть стек разработки, стек QA и стек Staging. В зависимости от размера вашего проекта QA может быть промежуточным, Производство может быть промежуточным или их комбинацией. Разделение стеков Dev и QA является наиболее важным.

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

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

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

person Richard Levasseur    schedule 20.03.2009

arrow_upward
1
arrow_downward

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

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

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

Мы поддерживаем синхронизацию наших структур БД с настраиваемым инструментом сравнения БД, который запускается во время развертывания.

person jonstjohn    schedule 19.03.2009
comment
Дополнительная информация о пользовательском инструменте сравнения баз данных, пожалуйста? Например, сравнивает ли он действующие базы данных или их текстовое представление с контролем версий? Сравнивает ли он только объекты схемы или также справочные данные (строки с контролем версий в нередактируемых таблицах)? - person Andrew Swan; 04.09.2009
comment
Мы создали специальный инструмент, который выполняет все сравнения баз данных на основе различных команд SQL, таких как статус показа таблицы, статус показа процедуры и т. Д. Мы используем MySQL. В более новой версии MySQL также можно использовать information_schema. - person jonstjohn; 04.09.2009

arrow_upward
1
arrow_downward

Старый пост, но интересный вопрос!

В моей компании сейчас:

  1. Создать новое репозиторий Github
  2. Настроить Jenkins
  3. Клонировать локально
  4. Начать филиал
  5. Разработать и добавить тесты (серверные, клиентские и e2e)
  6. Зафиксируйте каждый шаг и выберите команду + rebase, чтобы ветка была синхронизирована.
  7. Когда все будет готово, отправьте ветку на сервер: предварительная проверка lint и тесты и блокировка, если не в порядке
  8. Создайте пулреквест для ветки
  9. Здесь Дженкинс автоматически запускает тесты в ветке и помечает ее как «зеленую» или «сломанные тесты» непосредственно в запросе на перенос.
  10. Пусть по крайней мере 2 коллеги рассмотрят запрос на перенос и исправят свои выводы (вернемся к шагу 5).
  11. Когда все зеленое и 2 коллеги согласились, последний объединяет пулреквест.
  12. Удалить ветку на сервере
  13. Когда будете готовы, нажмите новую версию
  14. Последняя версия будет немедленно развернута на тестовой платформе
  15. QA проверить исправления и введенные функции (вернуться к 5, если проблема)
  16. (TODO) развернуть в предварительном продукте с параметрами, идентичными параметрам производства
  17. Развернуть в производство
  18. Приносите извинения пользователям за обнаруженные ошибки;) и сообщайте о них в диспетчере проблем.
  19. получать запросы функций и сообщать о них в диспетчере проблем
  20. перезапустить цикл на шаге 2
person Offirmo    schedule 28.02.2014