Как стать автором
Обновить

Комментарии 26

Что нового несёт эта заметка кэпа?
Ну как минимум информационный повод поболтать.
А вообще подобный метод, почему-то часто все игнорируют или считают чем-то сродним с чумой.
Без сарказма. Вы можете привести пример такой реализации на боевом проекте? Лично я, перед таем как запостить, потратил время на вопросы знакомым DevOps. И… не встретил такой реализации. Но все же, идея настолько проста и очевидна, что я ее отнес к лайфхакам и, заметьте, не претендую на новизну.
Почти наверняка её и нет на боевых проектах. А для маленького свечного заводика — идея действительно кажется простой и очевидной (другой пример из той же серии – хранение конфигов в системе контроля версий)
Хм… а в чем проблема для больших проектов? Деплой фронта же делается именно Ci/CD гита, так в чем трудность деплоить ту же статику, только не от девелоперов, а от маркетинга?
А почему вы считаете,
файлы все также генерируются в админке, затем они автоматом комитятся под пользователем, который их сгенерировал и пушатся в нужную репу. А далее, работает привычная магия CI/CD git.

не релизом?

Потому, что релиз это совокупность фич, которые прошли цикл разработки от бизнес-запроса, до тестирования.
А этот процесс не имеет признаков релиза. И называется просто — публикация. Ну требует оперативного выкатывания на прод. Т.е. в любой момент по желанию бизнеса.
НЛО прилетело и опубликовало эту надпись здесь
Для этого достаточно пуллить не в публичный каталог и выкладывать обновлённое хуками.
Для этого хуки не нужны. Можно указать расположение рабочего дерева (worktree) или через переменную окружения GIT_WORK_TREE, или через свойство core.worktree, или ключом --work-tree.

Тоже вариант, но хуками можно ещё и заполнять темплейты, данные в которых зависят от места деплоя. Не всем надо, конечно.
Идея-то стара — выгребать статику через сорс-контол, например давно известная «дырка» (точнее человекческая ошибка):
www.adamgotterer.com/post/28125474053/hacking-the-svn-directory-archive

Вопрос скорее технический, как вы чекаутите из гита отдельный файл (директорию)?
Простите, не понял вопроса. Про отдельный файл. Почему отдельный?
>> У нас генерировались такие файлы

Я так понял, что вы генерируете некую статику в виде надобра файлов, потом git add && git commit && git push в нужной комбинации, далее на серваке делаете pull/… что-то ещё, чтобы собстно выложить эти файлы (изменения в файлах) на веб.
Вопрос — что вы пуллите/чекаутите на веб?

Не совсем так.
1. git pull (получаем текущее состояние определенного бранча для данной задачи)
2. Перегенерируем все файлы. Все.
3. git add.
4. git commit -m "[тут инфа от маркетинга из админки о причинах]"
5. git push

Для простого случая это все. Далее запускается pipeline гита.

Про серверную инфру, простите, детально рассказать не могу, но по сути это git pull. Т.е. все, что нужно заливается и мы имеем крайний комит в продакшене.
>> Про серверную инфру, простите, детально рассказать не могу
Так это самое интересное.

>>по сути это 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/33578380
Я все понимаю, но не могу раскрывать детали прода. Прошу понять меня верно. Могу только одно сказать — там все хорошо. И строгое молчание о деталях прода, один из принципов нашей безопасности. Концепция доставки ничем, по сути, не отличается от концепции доставки релизов. И не несет рисков безопасности.
Эээ, странная позиция, как по мне. Ну да ладно.
НЛО прилетело и опубликовало эту надпись здесь
Включая.
Про серверную инфру, простите, детально рассказать не могу, но по сути это git pull

А как выглядит рабочая копия? Служебный каталог ".git" прямо внутри web-каталога или лежит отдельно?

Просто не все знают, что служебный каталог ".git" и файлы рабочей копии можно разнести, используя «core.worktree». И не засорять web-каталог служебными каталогами.
Git на проде нет. Так отвечу. И даже намека на него нет.
rsync на прод из админки нарушал гармоничную концепцию изолированности контуров. С переходном на транспорт git проблема решилась сама собой.

Это не значит, что внутри контура мы отказались от rsync.
Посмотрите hugo (gohugo).
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории