Стратегия развертывания приложения CFML с подрывной деятельностью?

Question

Наша команда использует SVN для отслеживания нашей повседневной разработки.Однако, когда дело доходит до развертывания в QA и Live, мы не уверены, что делать.

Слышал о Дженкинсе, но не уверен, хотим ли мы справляться с накладными расходами на изучение этого, если только это действительно не поможет нам в том, чего мы хотим.

Как использовать Branch или Tag для:

• простоты возврата к последнему рабочему состоянию
• отслеживание того, что развертывается, когда и что именно развертывается
• как отправить обновления в QA, а затем в Live

Прямо сейчас, каждый разработчик просто передает все в Head.Так что Head, хотя и стабилен, не гарантированно будет стабильным.

Использовать символическую ссылку?Виртуальная папка IIS?указать на версию вместо того, чтобы перезаписать для живого?Или Live должен быть экспорт из SVN?

Есть предложения?Спасибо!

Я немного боюсь ветвления / слияния в SVN, потому что если SVN говорит что-то не так, мы часто застряли там.

Существует несколько способов слияния, и если разработчик выберет неправильный путь, то svn будет испорчен, и кажется, что в SVN все просто отменить.

Мы не делаемхочу использовать Git сейчас ...

Answer 1

Во-первых, Jenkins - это автоматизированный сервер сборки, и, поскольку приложения ColdFusion не компилируются, он не поможет вам больше, чем svn.Я уверен, что есть некоторые привлекательные функции, которые доступны для приложений CF, но, как вы сказали, кривая обучения может не стоить усилий.

У нас те же уровни dev / QA / Prod, что и у вас, и SVN удовлетворяет наши потребности просто отлично.Процесс идет примерно так:

1. Разработчики проверяют ветку HEAD, используя Subclipse или TortoiseSVN
2. Разработчики проверяют функции в HEAD.
3. Системный администратор проверяетHEAD к QA-серверу, когда функции нуждаются в тестировании
4. Если HEAD проходит QA, создается ветвь для запуска в производство.Эта ветвь является просто копией HEAD, которая была проверена QA.Мы называем папку филиала prod_2_7_2012 или что-то подобное.
5. Системный администратор использует svn для извлечения проекта на рабочий сервер.Иногда полный экспорт и перезапись выполняются, если svn недоступен.
6. Разработчики проверяют ветку prod, используя subclipse / tortoise.Теперь у них есть 2 копии приложения в их среде разработки.
7. QA проверяет ветку prod.
8. Разработчики могут ТОЛЬКО фиксировать экстренные исправления ошибок в ветке prod, которые будут проверяться QA.
9. Если исправление утверждено, prod обновляется с помощью svn update или export.
10. Исправление также применяется к HEAD и фиксируется в HEAD.Это дублирует работу, но снимает головную боль слияния.
11. Когда новые функции в HEAD готовы к производству, процесс повторяется и старая ветвь продукта архивируется.

Без слияния.

Answer 2

Моя команда использует подход, который / транк должен быть в состоянии отправить в производство в любое время. Мы делаем всю разработку (как разработку функций, так и исправление ошибок) в отдельных ветках и создаем теги из ствола, когда выпускаем новую версию. Эти теги никогда не меняются после их создания.

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

Я видел несколько разных подходов к получению кода из тега на рабочий сервер. Маршрут, который мы сейчас используем, состоит в том, чтобы сделать рабочий сервер просто рабочей копией (извлеченной в определенный тег) и настроить Apache так, чтобы он не обслуживал файлы в папках .svn. Таким образом, когда выходит новая версия, это так же просто, как выполнить команду svn switch для нового тега и переустановить мое приложение. Кроме того, в SVN все аккуратно разделено, поэтому вы можете легко вернуться к предыдущим тегам, если что-то ускользнет от процесса обеспечения качества.

Не бойся слияния. Если вы не отставали от этого и не позволяли ему томиться неделями подряд между слияниями, это не имеет большого значения.

Answer 3

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

Ничто так не убивает производительность, как разрешение множества конфликтов из-за устаревшего хранилища.

Answer 4

Лучшее, что можно сделать, это изучить все рекомендуемые лучшие практики для ветвления и слияния.Это статья MSDN, касающаяся стратегии, но есть гораздо больше мнений: http://msdn.microsoft.com/en-us/library/ee782536.aspx

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

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