Рабочий процесс разработки для небольшой команды
Итак, я работаю в небольшой компании по организации мероприятий и развлечений и недавно взял на себя ответственность за команду разработчиков (PHP-приложения, большую часть времени). Текущий рабочий процесс выглядит примерно так:
- Для каждого проекта есть разработка и производственный сервер. Нет локальных сред разработки, это означает, что каждый разработчик имеет доступ по SSH и вносит изменения непосредственно на сервере разработки.
- Там нет контроля над источниками или что-либо еще.
- Большую часть времени каждый член команды работает над проектом самостоятельно. Несколько разработчиков, работающих над одним проектом, встречаются редко.
- Обновление рабочего сервера означает передачу исходного кода от разработчика на рабочий сервер с использованием SFTP.
Я нахожу это довольно ужасным, поэтому мне пришла в голову эта идея:
- Будет один центральный сервер разработки, на котором размещены все доступные проекты, этот сервер будет использовать Mercurial для контроля версий.
- Разработчики должны настроить локальную среду разработки и использовать локальный репозиторий для каждого проекта. Изменения могут быть извлечены / перенесены из / в центральное хранилище на сервере разработки.
- Если необходимо развернуть новую версию проекта, разработчик может просто клонировать репозиторий на рабочий сервер.
Что-то совершенно не так с таким рабочим процессом? Я использовал Mercurial для своих собственных проектов, но никогда раньше не использовал его в команде, и я новичок во всех этих вещах, связанных с управлением командой. Буду признателен за некоторые предложения.
Спасибо,
Крис
Решение
Очень важно, чтобы ваши разработчики работали локально. Самым большим преимуществом PHP является короткий цикл обратной связи, и если им приходится помещать потенциально испорченный материал в общий блок разработки, то это прерывает короткий цикл обратной связи. Возможно, вы сможете использовать что-то вроде Vagrant, чтобы упростить настройку среды для разработчиков на их машинах разработки.
Что касается остального: я бы отделил ваш сервер разработки / тестирования от вашего центрального хранилища. Причина в том, что, работая над своим проектом, вы, ребята, начнете использовать ветки для разных версий выпуска. Вполне вероятно, что будет «Стабильная» / текущая ветвь вашего проекта и «Особенная» ветка (Новые вещи, над которыми вы работаете). Выпуск напрямую на сервер разработки не имеет смысла даже для базового разветвленного рабочего процесса, как я предлагаю.
Другая большая проблема, которую я вижу здесь, заключается в том, что все ваши разработчики могут делать релизы на производственном сервере. Как правило, даже в небольших организациях перед выпуском на рабочий сервер назначается назначенное лицо и определенные критерии. Я бы порекомендовал вам сделать это. Также перед выпуском вы, ребята, должны ВСЕГДА отмечать версию, которую вы выпускаете. Это должно быть частью вашего рабочего процесса выпуска.
Другая вещь, которую вы не упоминаете, это отслеживание проблем. Насколько я понимаю, JIRA является золотым стандартом для программного обеспечения для отслеживания проблем. Нам нравится использовать JIRA и Fisheye для управления нашим кодом и координации коммитов с конкретными проблемами.
Другие решения
Вот рабочий процесс, с которым я работал в течение нескольких лет …
Несколько производственных серверов,
1 х Project (тестовый) сервер,
Git (Bitbucket),
Дженкинс,
JIRA (отслеживание проблем),
HipChat (командный чат)
1 х Master Git Branch,
1 х Project Git Branch
- Поднят новый билет (на JRIA)
- Оформить заказ на новый локальный филиал из основного филиала
- Выполнять работу
- Отправьте ветку для запроса извлечения (опубликуйте ссылку на запрос извлечения в командном чате, чтобы другие разработчики знали, если это PR) & внести любые необходимые изменения
- После утверждения слил мой местный филиал в проектный филиал
- Используйте Jenkins для клонирования проекта git repo, запуска тестов & развернуть на сервере проекта
- Тестер приложений проверяет все
- Билет пройден
- Слил мою локальную ветку в главную ветку и нажал
- Опять же, используйте Jenkins, чтобы клонировать ветку master и запустить тесты.
- Вручную попросите Дженкинса развернуть главную ветку на производственном сервере.
Я упомянул Jenkins выше, это может быть слишком далеко впереди для команды разработчиков, желающих внедрить новый процесс, а сейчас я бы предложил что-то более простое, такое как FTPloy, здесь есть довольно хорошее руководство по его настройке: https://daveismyname.com/website-deployment-with-bitbucket-and-ftploy-bp