Процесс разработки и производства

Question

Я видел, как части этой проблемы решаются по сети, но я все еще в замешательстве, поэтому я решил спросить об этом умных ребят из Stack Overflow.

Мы небольшой стартап, и на данный момент наш рабочий процесс от development -> production включает в себя загрузку ftp и просто загрузку кода разработчика.

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

Вот некоторые детали: - разработка на CakePHP + MySQL - Хостинг в Медиа Храме (GS) - разработчики используют Mac OS (Coda) и Windows (Dreamweaver)

Так что я спрашиваю: как настроить правильный масштабируемый рабочий процесс?

Answer 1

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

1) Создайте производственные выпуски и создайте схему версий, чтобы вы могли точно отслеживать свои выпуски. Отметьте каждый релиз, чтобы вы могли его отслеживать.

2) Сборка установщика. Не прибегайте к ручному копированию папок, потому что вы можете ошибиться. Инсталлятор также позволяет легко отслеживать, когда что-то идет не так в процессе производства.

3) Проведите некоторое тестирование на производстве перед развертыванием. Даже небольшой контроль качества проходит долгий путь. Разработчики не являются хорошими тестерами, поскольку они могут быть склонны к «особенностям» программы.

4) Пока что не беспокойтесь о ветках, пока вам действительно не понадобится их использовать. Только тогда станет ясно, какая структура вам нужна. Subversion red-book имеет несколько идей о том, как структурировать ваши ветви.

Answer 2

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

Я бы порекомендовал следующие вещи:

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

2. Автоматическая установка . Это незначительное преимущество, в то время как все еще находится на стадии быстрого развития, но в долгосрочной перспективе это высвободит ресурсы, которые можно было бы лучше потратить в других местах. Как минимум, у вас должен быть установочный пакет и шаги по установке для развертывания вашего кода.

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

4. Резервное копирование SVN . Это само собой разумеется, но я работал в компании, в которой наше хранилище исходных текстов не создавалось более двух лет. Вы можете сделать резервную копию, выполнив svndump и затем скопировав полученный файл в другое место. Вы также можете просто сделать резервную копию папок, в которых находится ваш репозиторий, а затем восстановить, если возникнут проблемы.

Answer 3

Один из способов, которыми я занимался в прошлом, - это заставить рабочий код на самом деле быть живым клиентом Subversion, вытягивая ветку 'production'.

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

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