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

Question

[1-800-IT]

Так сложилось, что приходится (пока что) в одиночку вести разработку, но ожидается пополнение в команде, а схема действий, что есть сейчас, совершенно к этому не готова.

Сейчас весь кодинг идет в PHPStorm, без локального сервера, по Ctrl+S идет разворачивание через SFTP на боевой сервер, по уму и во избежание проблем начал задумываться о git'е и отдельном сервере для тестирования. Как все грамотно должно выглядеть?

Пока моё представление такое:

1. Редактор по сохранению выгружает на второй сервер, максимально близкий по конфигам к первому
2. Проверяется работоспособность и отсутствие ошибок
3. Из редактора сабмитится в git
4. Из git'а разворачиваем на боевой сервер.
5. Во избежание расхождения и правок в экстренных случаях прямо на боевом - сливаем боевой как некоторые "срезы" в git, оттуда копируя на компьютеры и тестовый сервер
6. Раз в N времени синхронизировать базу тестового сервера с боевой версии

Проект специфичен (серверная часть для JS-скриптов, установленных на паре других сайтах) и переключение между тестовым и боевым, скорее всего, будет проводиться bat'ником, вписывающим разные IP (боевой/тестовый) для домена серверной части в hosts и сбрасывающий DNS-кеш локального компьютера.

А как разворачивать автоматически на боевой сервер последние ревизии с GIT'а? Как поступать с пользовательскими файлами и прочим, что не относится непосредственно к движку: аватары, временные файлы, файлы кеша?

Есть ли более совершенные схемы или готовые руководства по настройке такой схемы работы?

Answer 1

[Матвей Кукуй]

Не понятен пункт 5. Зачем сливать из боевого в гит? В гите должны храниться только исходные коды, по этому там всегда самая актуальная версия. И суть тестового сервера теряется из-за пункта 3. Обычно строится так:

Локальная машина разработчика -> пуш в git ветку test -> ci сервер сам накатывает ветку test на тестовый сервер -> разраб проверяет обновление -> мерж git ветки test с master -> ci накатывает ветку master на боевой сервер.

Параллельно по таймауту работают джобы по бэкапу боевого сервера на резервный, базы данных(mysqldump) и статики(rsync), например, раз в день с 3:00 до 4:00. Обновление базы на тестовом сервере обычно никак не автоматизируется, ибо там всегда каша из мусорных данных, которые наплодили автотесты.

Comments

[1-800-IT]

В ходе разработки часто приходится подбирать какие-то параметры или постоянно перезаливать варианты, что может выливаться в 6-7 проб от разработчика за минуту, которые он должен проверить на тестовом сервере. Сдается мне, что при таком раскладе легче просто заливать их на тест, чем засорять версиями тестовую ветку, или я не прав?

И что есть в терминологии CI-сервер?

[Матвей Кукуй]

CI сервер - сервер непрерывной интеграции, конкретно я использую и советую всем Jenkins. В таком случае, ваш разработчик должен использовать vagrant для воспроизведения "тестового сервера" у себя на компьютере. Тестировать на удаленном сервере - это очень плохой тон в случае когда есть 1 тестовый и 1 боевой. Попридержите коней, перестройте свое сознание. В лучших практиках тестовый сервер - это "почти то же самое что боевой", но на всякий случай на него не пускают пользователей. Это просто последняя проверка для тех случаев, если вы ответственно относитесь к качеству своего продукта. В этом и состоит смысл держать идентичные механизмы развертки и на тестовый и на боевой - их тоже стоит проверять. Если уж так необходимо, удлиняйте свою цепочку тестирования, введите 2-3 тестовых сервера. Например, на 1-м бардак и тесты каждые 2 минуты (желательно чтобы он был у разработчика на компьютере локально, о чем я написал выше), на 2-м тоже бардак и вакханалия но уже одна на всех разработчиков, на 3-м уже "чистовик", туда все релизят словно это боевой, затаив дыхание. Тот самый пробный запуск. На боевой уже выкатка с легким сердцем, все уверены в результате потому что то же самое только что произошло на 3-м этапе тестирования.

Answer 2

[Leonid Fedotov]

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

ЗЫ. Пользуюсь WebStorm, схема примерно такая же, всё работает. Единственное, все операции делаются через VPN-туннелирование из-за сервера на другом конце света :D

Comments

[1-800-IT]

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

[Leonid Fedotov]

1-800-IT: разве GIT или SFTP будут быстрее VPN-туннелирования при 200МБ кода? O_o

[1-800-IT]

Понял изначальный комментарий как отсутствие вообще каких-либо локальных файлов и работа исключительно с "шарой" - видимо, был неправ, поэтому описывал вариант с обязательным наличием локальных копий + синхронизацией лишь изменений через GIT.

[Leonid Fedotov]

Денис Сафронов: есть такая штука как WebStorm или PHPStorm, как Вам нравится. В обоих инструментах есть такая вещь как Sync with Deployed to Master. Всю вышеописанную логику выполняет всего-лишь один маленький клик.

Answer 3

[index0h]

Недавно был подобный вопрос