Как правильно работать с GIT если у тебя проекты CMS?
Приветствую, товарищи!
Решил перейти на модель работы с гитом но есть определенные трудности, которые не могу понять как решить.
Задача в следующем.
Есть сайт на определенной CMS, предположим ProcessWire, и нужно его разрабатывать с несколькими людьми.
1. При этои хочется работать через гит, и чтоб на продакшен сервере заливалось при пуше в мастер ветку.
2. Чтоб ещё была DEV ветка, которая сливается на дев сервер, при пушах в гит.
3. чтоб можно было писать локально в докер контейнерах.
4. Чтоб в гите была только нужная информация, сама CMS по идее в гите не нужна, нужны только шаблоны и модули.
5. Не понятно что делать с assets. (В ассетах лежат файлы всякие, которые например сами пользователи загрузили на сайт, или картинки к новостям и т.д.) По идее они не должны попадать в GIT, но тогда не понятно как это все синхронизировать между dev <-> prod <-> local у всех разрабов и серверов.
Посоветуйте какой нить материал, кто работает по таким или похожим схемам на разработке сайтов (БОЛЬШИХ САЙТОВ, которые весят большен пары сотен мегабайт) при этом в команде, при этом нормально чтоб я мог писать кусок локально, потом запушить его в гит, там его обработал какой-нить CI/CD и он попал на дев, там его посмотрели, обкатали, и этот кусок попал на PROD.
Заранее благодарен!
Вы что-то сильно заморачиваетесь..
Погуглите .gitignore для вашей cms и работайте в привычном себе режиме.
Заведите гитлаб или похожий менеджер проектов и пуште в него коммиты с номером таска.
5. Не понятно что делать с assets. (сами пользователи загрузили на сайт, или картинки к новостям и т.д.)
В игнор. За это отвечают ежедневные бэкапы (по крайней мере мы с напарником так договорились). Если что-то потеряется(что ну очень редко бывает) - можно достать оттуда.
1. билд–сервер + система деплоя по вкусу
2. аналогично п. 1
3. никакой связи с остальными пунктами
4. хранить в гите только то, что нужно
5. синхронизировать нужно только ассеты, имеющие непосредственное отношение к приложению (стили, скрипты, иконки, и т.п.) и они должны быть в гите. пользовательский хлам хранится в отдельной папке, которая просто линкуется при деплое в проект.
Супер, спасибо!
Эти ответы вытекают прамо из моих вопросов :)))
А есть решения, которые уже работают?
Я действительно этим и интересуюсь. Как правильно и аакиеикейсы используются.
1-2, а зачем две ветки, если все равно идет мерж из дева в мастер
3 пишите, кто мешает? Я не против, спросил у сереги(это кактус), он грит что тоже не против.
4 ну добавьте в гитигнор, было бы неплохо если бы cms грузилась через composer, тогда бы шла как вендор зависимость
5 их в гитигнор, у вас своя локальная копия, у юзеров своя, они никак не связаны. Учитывая что в cms вроде нет миграций, то можно периодически сливать дампы бд/файлов. Файлы хранить в gitlfs
Дженкинс не советую, лучше gitlab, он проще в настройке, у него встроенный ci/cd, у них в доках есть примеры.
1.2 - ну наверное чтоб не сломать мастер перед пулреквестом?
3. Никто не мешает, интересует как правильно и как реализовано в у нормальных комманд.
4. Это понятно, но как реализовано у других ?
5. Может правильно по другой схеме, я то интересуюсь :)))
Павел Дружинин,
1-2 ну тогда gitflow, а не dev/master
3 Сказать по правде я так и не понял что под этим имелось в виду, что писать, куда писать, зачем писать
4 Если php то через volume пробрасывают vendor зависимости, про cms не в курсе
5 Обычно разрабы не имеют вообще никакого доступа ни к каким пользовательским данным, ни к продовской базе. Представьте себе что будет если разраб вк будет иметь доступ к базе к вк, и тут вдруг его бросает девушка, что он тогда творить. А если это крупный банк и там проходят сотни тысяч транзакций с миллионами рублей.
5 Обычно разрабы не имеют вообще никакого доступа ни к каким пользовательским данным, ни к продовской базе. Представьте себе что будет если разраб вк будет иметь доступ к базе к вк, и тут вдруг его бросает девушка, что он тогда творить. А если это крупный банк и там проходят сотни тысяч транзакций с миллионами рублей.
grinat, а администратора базы данных, девушка не может бросить? :-)
Пример не корректен.
Сложный
