Git это круто! Ваш кэп

    Это, пожалуй, будет самая короткая моя статья. Более того, сама идея очевидная.

    Часто в WEB проектах возникают задачи доставки статики на прод вне релизов. Например, нужно выложить файлы для SPA с маркетинговой информацией: актуальные комиссии, свежий FAQ и т.п.

    У нас генерировались такие файлы из админки. Затем они разливались rsync-ком по нодам. Недостатков такого решения уйма. Организация логирования и контроль прав доступа, одни из самых серьезных.

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

    А далее, работает привычная магия CI/CD git.

    Более того, теперь нам доступны профиты о которых даже не думали — автоматический контроль фактического исполнения задач маркетингом через интеграцию Jira и gitlab.
    Поделиться публикацией

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

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

              не релизом?

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

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

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

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

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

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

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

                        >>по сути это 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
                          0
                          Я все понимаю, но не могу раскрывать детали прода. Прошу понять меня верно. Могу только одно сказать — там все хорошо. И строгое молчание о деталях прода, один из принципов нашей безопасности. Концепция доставки ничем, по сути, не отличается от концепции доставки релизов. И не несет рисков безопасности.
                            +1
                            Эээ, странная позиция, как по мне. Ну да ладно.
                              +2
                              И строгое молчание о деталях прода, один из принципов нашей безопасности.

                              Security through obscurity?

                                0
                                Включая.
                            0
                            Про серверную инфру, простите, детально рассказать не могу, но по сути это git pull

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

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

                              Это не значит, что внутри контура мы отказались от rsync.
                      0
                      Ну, или перефразируя предыдущий вопрос: а у вас код и статика лежат в одном репозитории, или в разных?
                        0
                        Теперь понял. Разные.
                        0
                        Посмотрите hugo (gohugo).

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое