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

Хьюстон, у нас проблемы. Проблема номер один - я не пользовался системами контроля версий до 2019 года. Собственно, из нее вытекает и набор других проблем, породивших этот вопрос. Суть в чем - я пытаюсь в голове разложить процесс "правильной" разработки вебсайта, чтоб все как у людей - с нормальным версионированием, непрерывной интеграцией и максимальной автоматизацией. Но не очень понимаю стек инструментов, которыми это все можно и нужно рулить.
Если позволите, покажу весь масштаб проблемы на примере небольшого пет-проекта.
Проект - вебсайт на php/Laravel + vuejs + mysql + небольшой набор всяких bash-скриптов.

Как сейчас происходит разработка: случайно и чудом.
1. Собсно, пишу код. Коммичу в dev-ветку все, что плохо лежит (все то, что laravel по умолчанию не выпилил из-под гита)
2. dev-ветку ручками делаю clone на тестовый сервак (локальная машина с окружением, сходным с prod-сервером) в отдельный каталог (не в тот, который рут для сайта)
3. Собираю composer'ом и npm'ом back и front
4. Перемещаю собранный готовый проект в рут-папку сайта
5. Плачу от отсутствия тестов (знаю, что надо, но не понимаю, что нужно тестировать и как)
6. Руками гоняю (гусары, молчать) возможные состояния основных добавленных функций.
7. Если все проходит хорошо, то сливаю ветку с мастером и повторяю процедуру уже с прод-сервером

После нескольких мануалов по unit-тестированию, selenium ide, git, svn и всяких жутких вещах вроде CD\CI (конкретно читал про TeamCity) в голове каша. Мозгом понимаю, что каждый из этапов можно делать лучше. Но какой стороны подойти - хз. Так что, комрады, очень надеюсь на помощь по нескольким вопросам.

1. Разработка.
Стараюсь делать хорошо. После многих лет попыток делать хоть как-то, но быстро - не всегда получается, но потихоньку идет. Паттерны, рефакторинг - уже не просто пустой звук.
Для laravel рекомендуют наращивать функционал пакетами. Собственно, так и делаю. Не уверен, что это можно назвать пакетами, но делаю. Имеет ли смысл такой подход, когда в проекте, предположим, используется разный функционал, который не связан друг с другом? (например, магазин - один пакет, оповещения - другой пакет). Или, может, наоборот, стоит разбивать на более мелкие элементы (типа не отдельный пакет магазина, а поделить на Корзину/Склад/Доставку и т.п.)?

2. Тестирование.
Читал про TDD, пробовал делать - понравилось. Не слишком понравилось, ибо голова так думать не привыкла, но зашло. Возник вопрос - что именно надо тестировать и как выбрать набор тестов? Я всегда ориентировался на 3 варианта использования любого функционала - ожидаемый правильный, ожидаемый неправильный и неожиданный неправильный. Не уверен, что это верно, т.к. это просто выбор пальцем в небо. Если знаете, где почитать/послушать про это дело, буду весьма признателен за информацию.

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

3. Контроль версий
Продолжение безумия. Освоил простой путь - тупо храню в vcs ветку с результатами разработки. Но, опять же, здравый смысл подсказывает, что при хреновой памяти и перерывах между коммитами в несколько месяцев надо что-то менять. Как минимум, я не уверен, что правильно хранить все пакеты в одним месте. Однако как сделать правильно - не знаю. С одной стороны, можно вообще пакеты хранить в разных репозиториях и при необходимости перебирать только их. С другой - если большинство из них используются только в одном проекте (хотя могут, потенциально, и еще где-нибудь пригодиться), имеет ли смысл делить все настолько? Или это выносить как часть gitflow и каждый пакет будет чисто feature-веткой?

Про БД читал, что имеет смысл хранить лог запросов и спихивать в vcs именно этот лог. Хорошая ли затея в целом? Или есть какие-то более правильные методы (При условии, что субд MySQL)?

4. Деплой.
Читал где-то занимательную фразу типа "прекратите деплоить, делая clone на production". Я бы и рад, да только как и куда копать? Сдается мне, тут должен помочь TeamCity, но пока что я в него как баран на новые ворота.
Предположим, что код написан, тесты на dev пройдены и пришло врем сделать так, чтобы текущая ветка мастера внезапно оказалась на боевом серваке. Как правильно организовать эту самую доставку кода? В какой момент собирать приложение? Тестировать ли сборку на prod-сервере (при условии, что идентичен dev)?

5. Документирование
С docblock в php все более-менее хорошо, тут иногда даже помогает. Читал, что тесты фронтенда можно использовать в качестве документации/пользовательских мануалов. В каком виде лучше хранить документацию и нужна ли она для конечного продукта (предположим, что бэкендом может заниматься некоторый абстрактный разработчик, а на фронте временами и клиент может бывать, который не знает о системе ничего и не отказался бы от мануала по использованию)? Опять же, если это подход из прошлого века - просветите, пожалуйста, по поводу новинок всего этого.
  • Вопрос задан
  • 3297 просмотров
Решения вопроса 1
index0h
@index0h
PHP, Golang. https://youtube.com/index0h
Разработка и контроль версий

Читаем про git flow, восхищаемся и интегрируем.
Читаем PSR-ы, восхищаемся и интегрируем. Не помешает: Попросили проверить код, на что смотреть нужно?
Читаем про vagrant. На базе вот этого вот строим dev окружение. Можете поиграть с https://puphpet.com/. До docker все же стоит дорасти.
Постигаем Phpstorm, и радуемся жизни.
Можете посмотреть так же: https://github.com/index0h/php-conventions/tree/fe... я пока что не закончил, но написанную часть можно взять на вооружение.

Тестирование

Читаем про phpunit, восхищаемся и интегрируем.

Документирование

Рекомендую взять за правило: документирование алгоритмов нужно только в крайнем случае, когда используются некие хаки. Говнокод лучше переписать на что-то очевидное, чем объяснять, какая муха вас укусила и где.
Что касается docblock-ов для помощи ide - это отличная идея.

Деплой

Самый простой и надежный способ: root у вашего nginx/apache указывать как ссылку на каталог текущей прод версии. При релизе - заливать код с помощью rsync в новый каталог, а далее менять ссылку на новый релиз.
Например у вас каталог с версиями кода:
production -> v1.0.2 - текущая версия
v1.0.1 - старый релиз
v1.0.2 - текущая версия
v1.0.3 - новый релиз
Когда подготовка завершена - вы только меняете симлинк production на v1.0.3. Если что не так - можно быстро откатиться на предыдущую версию.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
@marataziat
Джангист-такторист
Сайт нужно засунуть в Kubernetes контейнеры, и когда прилетает на CI сервер оповещение о новом коммите то запустить деплой.

Надо гуглить laravel kubernetes ci

Выбери какой ci ты хочешь, например gitlab имеет бесплатный ci и git хостинг или сам создашь свой на gitea с jenkins ci!

Вариантов куча, но я считаю что от веб серверов в привычном понимании надо отказыватся и все ставить в kubernetes
Ответ написан
@le1ic
Как выше сказали, освойте gitflow. Тогда у вас будет основной бранч и пул-реквесты (aka мердж реквесты). Начните использовать github, он неявно благоприятствует этой модели. Потом потихоньку настройте в github разные интеграции. Lint/syntax checker для начала, у вас уже будет подобие CI. Потом начните прикручивать тесты. Это все тоже можно сделать на github. Далее, continuous deploy тоже можно сделать через github. На мой взгляд, по крайней мере для осваивания всего этого, github - идеальная платформа. А потом, если вам у вас какие-то слишком специфические требования, вы можете уже пробовать что-то другое или свое, но у вас уже будет модель, с которой вы будете сверяться и либо ее повторять, либо осознанно отступать.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
17 окт. 2019, в 22:21
250000 руб./за проект
17 окт. 2019, в 19:04
300 руб./в час
17 окт. 2019, в 19:01
500 руб./в час