Часто в WEB проектах возникают задачи доставки статики на прод вне релизов. Например, нужно выложить файлы для SPA с маркетинговой информацией: актуальные комиссии, свежий FAQ и т.п.
У нас генерировались такие файлы из админки. Затем они разливались rsync-ком по нодам. Недостатков такого решения уйма. Организация логирования и контроль прав доступа, одни из самых серьезных.
Однажды пришла идея использовать git для доставки маркетинговой статики на прод. Т.е. файлы все также генерируются в админке, затем они автоматом комитятся под пользователем, который их сгенерировал и пушатся в отдельную, маркетинговую репу.
А далее, работает привычная магия CI/CD git.
Более того, теперь нам доступны профиты о которых даже не думали — автоматический контроль фактического исполнения задач маркетингом через интеграцию Jira и gitlab.
Комментарии (26)
rezdm
15.04.2019 15:45Идея-то стара — выгребать статику через сорс-контол, например давно известная «дырка» (точнее человекческая ошибка):
www.adamgotterer.com/post/28125474053/hacking-the-svn-directory-archive
Вопрос скорее технический, как вы чекаутите из гита отдельный файл (директорию)?
rpiontik Автор
15.04.2019 15:52Простите, не понял вопроса. Про отдельный файл. Почему отдельный?
rezdm
15.04.2019 15:58>> У нас генерировались такие файлы
Я так понял, что вы генерируете некую статику в виде надобра файлов, потом git add && git commit && git push в нужной комбинации, далее на серваке делаете pull/… что-то ещё, чтобы собстно выложить эти файлы (изменения в файлах) на веб.
Вопрос — что вы пуллите/чекаутите на веб?
rpiontik Автор
15.04.2019 16:05Не совсем так.
1. git pull (получаем текущее состояние определенного бранча для данной задачи)
2. Перегенерируем все файлы. Все.
3. git add.
4. git commit -m "[тут инфа от маркетинга из админки о причинах]"
5. git push
Для простого случая это все. Далее запускается pipeline гита.
Про серверную инфру, простите, детально рассказать не могу, но по сути это git pull. Т.е. все, что нужно заливается и мы имеем крайний комит в продакшене.rezdm
15.04.2019 16:15>> Про серверную инфру, простите, детально рассказать не могу
Так это самое интересное.
>>по сути это git pull
Это подразумевает клон репозитория на веб-сервере, что есть не совсем гуд. Собстно об этом и вопрос.
Вот это вот всё:
stackoverflow.com/questions/1125476/retrieve-a-single-file-from-a-repository
stackoverflow.com/questions/2466735/how-to-sparsely-checkout-only-one-single-file-from-a-git-repository/33578380rpiontik Автор
15.04.2019 16:17Я все понимаю, но не могу раскрывать детали прода. Прошу понять меня верно. Могу только одно сказать — там все хорошо. И строгое молчание о деталях прода, один из принципов нашей безопасности. Концепция доставки ничем, по сути, не отличается от концепции доставки релизов. И не несет рисков безопасности.
multiadmin
15.04.2019 17:33Про серверную инфру, простите, детально рассказать не могу, но по сути это git pull
А как выглядит рабочая копия? Служебный каталог ".git" прямо внутри web-каталога или лежит отдельно?
Просто не все знают, что служебный каталог ".git" и файлы рабочей копии можно разнести, используя «core.worktree». И не засорять web-каталог служебными каталогами.rpiontik Автор
15.04.2019 18:02Git на проде нет. Так отвечу. И даже намека на него нет.
rsync на прод из админки нарушал гармоничную концепцию изолированности контуров. С переходном на транспорт git проблема решилась сама собой.
Это не значит, что внутри контура мы отказались от rsync.
Koneru
Что нового несёт эта заметка кэпа?
tsukasa_mixer
Ну как минимум информационный повод поболтать.
А вообще подобный метод, почему-то часто все игнорируют или считают чем-то сродним с чумой.
rpiontik Автор
Без сарказма. Вы можете привести пример такой реализации на боевом проекте? Лично я, перед таем как запостить, потратил время на вопросы знакомым DevOps. И… не встретил такой реализации. Но все же, идея настолько проста и очевидна, что я ее отнес к лайфхакам и, заметьте, не претендую на новизну.
aamonster
Почти наверняка её и нет на боевых проектах. А для маленького свечного заводика — идея действительно кажется простой и очевидной (другой пример из той же серии – хранение конфигов в системе контроля версий)
rpiontik Автор
Хм… а в чем проблема для больших проектов? Деплой фронта же делается именно Ci/CD гита, так в чем трудность деплоить ту же статику, только не от девелоперов, а от маркетинга?
arandomic
А почему вы считаете,
не релизом?
rpiontik Автор
Потому, что релиз это совокупность фич, которые прошли цикл разработки от бизнес-запроса, до тестирования.
А этот процесс не имеет признаков релиза. И называется просто — публикация. Ну требует оперативного выкатывания на прод. Т.е. в любой момент по желанию бизнеса.
eugene_bx
Для статических файлов (около ста тысяч файлов, обновление не очень частые, несколько сотен в день) у нас есть подобная система для большого проекта (миллионы пользователей в день), только вместо git у нас TFS.
YemSalat
Главное папочку .git не забыть закрыть от публики на сервере.
Stanislavvv
Для этого достаточно пуллить не в публичный каталог и выкладывать обновлённое хуками.
multiadmin
Для этого хуки не нужны. Можно указать расположение рабочего дерева (worktree) или через переменную окружения GIT_WORK_TREE, или через свойство core.worktree, или ключом --work-tree.
Stanislavvv
Тоже вариант, но хуками можно ещё и заполнять темплейты, данные в которых зависят от места деплоя. Не всем надо, конечно.