Ответы пользователя по тегу Непрерывная интеграция
  • Docker - архитектурные вопросы о деплое и не тольно?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1) nginx-proxy
    2) копируйте исходники в образ (в dockerfile), собирайте либо локально либо на CI-сервере эти образы и пушьте их в docker/distribution (либо платный docker-hub либо разверните свой, это с докером делается за минут 10).
    3) Прямо в контейнере с PHP. Либо заведите отдельный контейнер для php-cli и зачедите отдельный контейнер для исходников, и через volumes_from расшарьте между ними. Вариант с cron на хосте тоже достоен существования, но это не ок в большинстве случаев.
    4) обновлять базовый образ. А там уж как организуетесь.
    5) Можно, смотрим пункт 2.
    6) Вообще тут можно схитрить. Вы можете же хранить зависимости прямо в репозитории, в смысле коммитить вендоры. Но вы этого не делаете. На момент когда запускается docker build ваших образов, все зависимости уже должны поставиться. И для каждого из перечисленных вами средств разработки уже есть свой контейнер, готовый. Берем и юзаем.
    7) как мы выяснили в пункте 6 - композера на проде быть не должно. вообще как, вы оттещенный образ со стэйджинга должны просто "мувать" на продакшен. В этом плане риски при релизе минимальны.
    8) тут опять же по разному. Мне удобнее прямо из контейнера коннектиться например в sentry или graylog и скидывать туда логи. Ну или мы должны пихать логи в stdout/stderr контейнера и далее агрегировать их снаружи, тут так же есть куча вариантов.
    9) все это отдельные контейнеры, все это вместе связывается башем и docker-compose. Все это разварачивается либо через docker-machine и CI либо просто через CI. Docker-machine будет "удобным" только с версии 0.7 или 0.8.
    Ответ написан
    2 комментария
  • Доставка проекта на продакшен, какие инструменты для деплоя?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    docker

    собираем на CI-ке контейнер, прогоняем на нем тесты (вы же сказали что проект большой, большой проект без тестов - боль), если все хорошо - пушим в docker hub или в свой локальный docker distribution, после чего можно на серваке сделать просто docker-compose pull && docker-compose up -d и радоваться.
    Ответ написан
  • Что такое build agent в CI?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    да, это сервер на котором происходит сборка. У меня скажем есть один мастер сервер где установлен Jenkins, и 3 агента (один на маке для сборки под iOS и два на linux для андроида и вэба).

    выполняют build на клиенте

    Лучше отдельный сервак. CI-ка всегда должна иметь доступ к своим слэйвам. Хотя думаю можно извратиться.
    Ответ написан
    1 комментарий
  • Continuous Deploy. Не только вперед по истории коммитов git, но и экстренно назад?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Docker + Ansible. При деплое поднимаете контейнер с новой версией приложения (старая версия в скоем контейнере и пока работает), накатываете миграции (условие - миграции одной версии не должны вести к неработоспособности старой, иначе у вас проблемы с проектированием базы), подменяете текущий контейнер на новый и тушите его. Если вдруг что-то пошло не так, запускаете скрипт который проведет операцию в обратном направлении.

    Если Docker смущает своей молодостью, есть вариант с оформлением приложения в виде DEB-пакета.

    А еще есть Capistrano.

    p.s. Довольно интересная тема, но на большинстве проектов, с которыми довелось сталкиваться или общаться с разработчиками оных, популярна стратегия "фиксить АСАП!" (за редкими исключениями, причем даже если минута простоя стоит тысячи долларов). Обычно это связано с тем что такие ситуации не случались ибо все предварительно обкатывается на стэйджинге с копией реальных данных.
    Ответ написан
    2 комментария
  • Как организовать процесс разработки продукта на C++, используя GIT?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    то что вы описывается называется feature-branch.
    ваши фича-брэнчи должны всегда быть синхронизированны с мастером. У всех разработчиков должна быть актуальная версия кода, с которым они работают. В этом смысле подход с feature-branch, особенно когда речь идет о больших изменениях, может сильно рассинхронизировать код между разработчиками.

    Мне больше нравится подход с Feature Toggle, так как он более соответствует философии git.
    Ответ написан
    Комментировать