Как структурировать разработку веб-приложений?

Question

[Денис Бушаев]

Добрый день.
Есть ли у кого опыт автоматизации и структуризации(оптимизации) разработки в стеке бек на php фронт на node?
Конкретный пример, команда из 2х разработчиков.
Раньше делали modx сайты, сейчас пробуем отказаться от modx фронта, но на роль cms не нашлось лучшего кандидата для наших целей, кроме как тот же modx.
Сейчас сделали апишку на modx, подтягиваем данные на фронт.
Что меня сейчас смущает. Есть ли смысл контейнезировать фронт и/или бэк? Какие в этом плюсы. Если да - то как схематично построить работу.
Сейчас в планах попробовать такую схему:

• 1. Пишем код
  
• 2. Пушим в dev ветку
  
• 3. Собираем на dev сервер
  
• 4. Проверяем dev версию
  
• 5. Если всё ок - пункт 6, если есть баги то возвращаемся в пункт 1
  
• 6. Мерджим в master ветку
  
• 7. Собираем на рабочем сервере
  

Answer 1

[Alex Wells]

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

docker-compose'ом это собрать выйдет в 10 раз быстрее, и на сервере нужно будет буквально только docker и поставить. Конечно, начать с простенького варианта (просто один компоуз на все окружения).

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

Второй вариант лучше всего с ПРами, а не мерджами напрямую в главную, даже если из команды их никто не смотрит - просто потому что девелопер сможет посмотреть, че он там накалякал перед мерджом. Ну и CI/CD ерунда автоматически становится доступной и простой, если речь об любом популярном git хосте (github/gitlab/bitbucket).

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

Comments

[Денис Бушаев]

Спасибо за развернутый ответ и пояснения. Стало немного понятнее.

Answer 2

[Vitsliputsli]

Зачем? Что вы хотите получить? Что вам не нравится сейчас?
Нет универсальных решений, чтобы все было хорошо, смотреть нужно по ситуации. К примеру, есть ли смысл контейнеризировать, на это вы сможете ответить только сами. Прикиньте плюсы и минусы, стоит ли сейчас тратить на это время, чтобы получить сомнительные (а может и нет) плюсы. Когда для всех разработчиков есть одинаковое готовое окружение - это хорошо, но когда эти все - 2 человека, стоит задуматься.
Насчет схемы, опять же, что вы хотите ей решить, что есть у вас сейчас. Если этой схемой вводите ветку dev - отлично, будет где интегрироваться разработчикам. Сказать, что это должно быть must have - да, но для спринтовой релизной системы, при rolling releases и отсутствии постоянной необходимости интегрироваться - не обязательно.
Если же хочется просто следовать трендам, то по этим вопросам docker и git-flow.

Answer 3

[dmitriy]

1. схема нормальная, работаем сейчас по аналогичной
2. докер в любом случае поможет использовать одно окружение для все разработчиков, CI для проекта

Answer 4

[Sanes]

Замените Docker на Ansible и работайте с нормальным окружением.