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



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

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

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

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

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

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

Вы можете помочь и перевести немного средств на развитие сайта

Теги:



Комментарии (26):

  1. Koneru
    /#20029390

    Что нового несёт эта заметка кэпа?

    • tsukasa_mixer
      /#20029418 / +2

      Ну как минимум информационный повод поболтать.
      А вообще подобный метод, почему-то часто все игнорируют или считают чем-то сродним с чумой.

    • rpiontik
      /#20029422

      Без сарказма. Вы можете привести пример такой реализации на боевом проекте? Лично я, перед таем как запостить, потратил время на вопросы знакомым DevOps. И… не встретил такой реализации. Но все же, идея настолько проста и очевидна, что я ее отнес к лайфхакам и, заметьте, не претендую на новизну.

      • aamonster
        /#20029502

        Почти наверняка её и нет на боевых проектах. А для маленького свечного заводика — идея действительно кажется простой и очевидной (другой пример из той же серии – хранение конфигов в системе контроля версий)

        • rpiontik
          /#20029556

          Хм… а в чем проблема для больших проектов? Деплой фронта же делается именно Ci/CD гита, так в чем трудность деплоить ту же статику, только не от девелоперов, а от маркетинга?

      • arandomic
        /#20029510

        А почему вы считаете,

        файлы все также генерируются в админке, затем они автоматом комитятся под пользователем, который их сгенерировал и пушатся в нужную репу. А далее, работает привычная магия CI/CD git.

        не релизом?

        • rpiontik
          /#20029560

          Потому, что релиз это совокупность фич, которые прошли цикл разработки от бизнес-запроса, до тестирования.
          А этот процесс не имеет признаков релиза. И называется просто — публикация. Ну требует оперативного выкатывания на прод. Т.е. в любой момент по желанию бизнеса.

      • eugene_bx
        /#20029726 / +2

        Для статических файлов (около ста тысяч файлов, обновление не очень частые, несколько сотен в день) у нас есть подобная система для большого проекта (миллионы пользователей в день), только вместо git у нас TFS.

      • YemSalat
        /#20030550

        Главное папочку .git не забыть закрыть от публики на сервере.

        • Stanislavvv
          /#20031882

          Для этого достаточно пуллить не в публичный каталог и выкладывать обновлённое хуками.

          • multiadmin
            /#20033340 / +1

            Для этого хуки не нужны. Можно указать расположение рабочего дерева (worktree) или через переменную окружения GIT_WORK_TREE, или через свойство core.worktree, или ключом --work-tree.

            • Stanislavvv
              /#20034250

              Тоже вариант, но хуками можно ещё и заполнять темплейты, данные в которых зависят от места деплоя. Не всем надо, конечно.

  2. rezdm
    /#20029550

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

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

    • rpiontik
      /#20029574

      Простите, не понял вопроса. Про отдельный файл. Почему отдельный?

      • rezdm
        /#20029600

        >> У нас генерировались такие файлы

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

        • rpiontik
          /#20029634

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

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

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

          • rezdm
            /#20029682

            >> Про серверную инфру, простите, детально рассказать не могу
            Так это самое интересное.

            >>по сути это 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

            • rpiontik
              /#20029698

              Я все понимаю, но не могу раскрывать детали прода. Прошу понять меня верно. Могу только одно сказать — там все хорошо. И строгое молчание о деталях прода, один из принципов нашей безопасности. Концепция доставки ничем, по сути, не отличается от концепции доставки релизов. И не несет рисков безопасности.

              • rezdm
                /#20029764

                Эээ, странная позиция, как по мне. Ну да ладно.

              • staticlab
                /#20031654 / +2

                И строгое молчание о деталях прода, один из принципов нашей безопасности.

                Security through obscurity?

          • multiadmin
            /#20030012

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

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

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

            • rpiontik
              /#20030128

              Git на проде нет. Так отвечу. И даже намека на него нет.
              rsync на прод из админки нарушал гармоничную концепцию изолированности контуров. С переходном на транспорт git проблема решилась сама собой.

              Это не значит, что внутри контура мы отказались от rsync.

  3. MrFrizzy
    /#20029646

    Ну, или перефразируя предыдущий вопрос: а у вас код и статика лежат в одном репозитории, или в разных?

  4. neenik
    /#20030208

    Посмотрите hugo (gohugo).