Непрерывная Интеграция — Лучший Способ Создать Конвейер Ci/Cd Для Уменьшения Количества Ошибок И Облегчения Рефакторинга.

Я начал проект с небольшой командой (3 человека), и нам пришлось многое взломать, и мы создали большое приложение без модульных тестов, полагаясь только на руководство. Сейчас у нас огромный технический долг и мы начали внедрять CI/CD. Наша цель — начать повсеместно проводить кипарисовые тесты, затем несколько модульных тестов и рефакторинг кода, а также реализовать инструменты статического анализа в конвейере Ci/CD:

Наша идея состоит в том, что у нас не будет локальной среды, а будет только серверная среда. Таким образом, разработчик отправляет код в Gitlab, исполнитель Gitlab в Digital Ocean отправляет репозиторий на промежуточный сервер, разработчик выполняет отладку в Digital Ocean с помощью Local Cypress Runner и своих собственных модификаций, если он что-то сломает или забудет выполнить полный регрессионный тест или тест командной строки. исполнитель регрессии запускается ДО второго развертывания, поэтому он не позволяет коду передаваться на сервер развертывания/производства.

Вопросы

1: нужно ли нам отделять среду развертывания от промежуточной установки в двух каплях? можем ли мы достичь этой конфигурации без серьезных проблем в одной и той же капле?

2: нужно ли нам использовать докер? если нет, то как это следует сделать

3: какую настройку мы можем сделать, чтобы сократить ручную работу? наша проблема не в одобрении, а в максимальной автоматизации, поскольку у нас нет специалиста по ИТ/DevOps и нет контроля качества.

Примечание: первый этап — реализация полной регрессии, второй этап — реализация инструментов качества кода (статических анализаторов), таких как sonarqube, phpStan и т. д.

Стек: стек LAMP с PHP Codeigniter и vanilla JS.

Сейчас это может быть неочевидно, но обычно по мере продвижения проекта затраты на полную регрессию (ресурсы/время) растут намного быстрее, чем затраты на статический анализ.

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

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

В дальнейшем вы, вероятно, обнаружите, что выполнение полной регрессии и/или полного статического анализа на более ранних этапах конвейера может легко стать узким местом:

• если вы заблокируете другие коммиты во время ожидания результатов выполнения, вы замедлите скорость коммитов
• если вы разрешите другие фиксации во время выполнения, они изменят контекст репозитория, потенциально делая недействительными результаты предыдущего запуска (например, вы не можете немедленно исправить ошибку времени выполнения, обнаруженную при запуске, если последующая фиксация, произошедшая в это время, вызывает перерыв во время сборки).

Устранение этих узких мест обычно означает разделение таких прогонов на два основных функциональных этапа (каждый из которых фактически может состоять из нескольких подэтапов и/или шагов):

• тот (предварительная) интеграция этап(ы), которые выполняют подмножества из этих запусков на более ранних этапах конвейера:

  • короче — для поддержания достаточно высокого уровня коммитов и избежания узких мест
  • целевой уровень качества ниже уровня развертывания, но достаточно высок, чтобы продолжать разработку
  • исправление регрессий, обнаруженных на этих этапах, имеет высокий приоритет.
  • такие прогоны можно использовать для шлюзования коммитов/слияний, чтобы предотвращать скорее, чем обнаружить и исправить регрессии, и в этом случае они фактически будут предварительная интеграция этапы

• тот постинтеграция этапы, выполняющие более длительную/полную регрессию и/или статический анализ:

  • целью здесь будет просто повышение качества до уровня развертывания (т. е. блокирование фактического развертывания, если оно не достигнуто)
  • регрессии, обнаруженные на этом этапе, не блокируют разработку, их исправление имеет более низкий приоритет.

Пожалуйста, ниже, где я отвечаю на конкретные вопросы.

2: нужно ли нам использовать докер? если нет, то как это следует сделать

Используя Docker, вы можете автоматизировать настройку образов вашего сервера, а также образов приложений, которые будут использоваться для развертывания в промежуточной и рабочей среде.

Docker использует стандартные образы, на основе которых вы добавляете в образ свою собственную установку программного обеспечения и команды. Поскольку Docker предназначен для запуска одной службы в каждом контейнере (работающий образ), вы также можете начать разделять свои приложения на микросервисы.

Взгляните на «образы», ​​«контейнеры» и «Dockerfiles» Docker, чтобы понять принципы и архитектуру.

Преимущества автоматизации вашей инфраструктуры с помощью образов Docker, созданных с помощью Dockerfiles, многочисленны:

- Ваша настройка становится менее подверженной ручным ошибкам.

- Более быстрое развертывание сервисов (вашего приложения или программного обеспечения) на этапе подготовки, а также в производстве. Вы можете пакетно раскручивать контейнеры.

- Упрощенный обзор задач, связанных с настройкой ваших серверов. Когда вы начинаете писать Dockerfiles, вы отвлекаетесь от мыслительного процесса как разработки, так и эксплуатации, потому что вам приходится писать последовательные команды для настройки серверов. Это приводит к более глубокому пониманию вашего собственного конвейера и того, как его можно улучшить.

3: какую настройку мы можем сделать, чтобы сократить ручную работу? наша проблема не в одобрении, а в максимальной автоматизации, поскольку у нас нет специалиста по ИТ/DevOps и нет контроля качества.