CI/CD - Идеальный pipeline - Георг Гаал

• Приветствие и представление участников: Феделина и Георг Галл.  

• Тема стрима: существование идеального пайплайна.  

• Введение в тему DevOps и создание непрерывного цикла поставки.  

• Описание процесса DevOps: создание новых версий ПО, тестирование, доставка, сбор обратной связи.  

• Важность практик CI/CD для улучшения процесса.  

• Определение CI: интеграция изменений в основной код.  

• Преимущества: минимизация конфликтов изменений, постоянное тестирование.  

• Автоматизация процесса проверки изменений.  

• Определение CD: процесс непрерывной доставки.  

• Различие между CD и CI: CD подразумевает выкатывание продукта, CI - интеграцию изменений.  

• Важность быстрого выкатывания фич.  

• Различие между CI и CD на разных этапах жизненного цикла продукта.  

• Использование различных инструментов для CI и CD.  

• Примеры: Gitlab, Jenkins, Ant.  

• Различие между коробочными и облачными продуктами.  

• Особенности разработки и тестирования для разных типов продуктов.  

• Использование фича флагов для облачных сервисов.  

• Фича флаги: включение и выключение функциональности для разных пользователей.  

• Об тестирование: проверка гипотез и разделение пользователей на категории.  

• Различие в реализации и применении технологий.  

• Именование переменных - это конвенция, которая варьируется в разных компаниях.  

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

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

• Идеальный пайплайн - это философский вопрос, зависящий от наблюдателя.  

• Пайплайн должен быть лаконичным и легко расширяемым.  

• Важно, чтобы пайплайн был стабильным и не флейки.  

• Пайплайн должен быть быстрым и стабильным.  

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

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

• Пайплайн начинается с машины разработчика.  

• Используются инструменты для отсечения неправильного форматирования и выполнения минимального набора тестов.  

• Разработчик настраивает свою рабочую машину и использует утилиты, такие как прикомит.  

• После коммита в удаленный репозиторий, начинается более глубокая проверка кода.  

• Используются линтеры для проверки форматирования и соответствия стандартам.  

• Важно выбирать баланс между проверками и ложными срабатываниями.  

• Инструменты для пайплайна включают GitHub, GitLab, Bitbucket и другие.  

• Эти инструменты позволяют быстро создавать и настраивать пайплайны.  

• Antis не является инструментом для построения пайплайна, но полезен для настройки серверов.  

• Инструменты для пайплайнов являются оркестраторами задач.  

• Они позволяют выполнять различные этапы, такие как сборка и тестирование.  

• GitOps и другие подходы замещают часть пайплайнов, но не являются их полной заменой.  

• После запуска пайплайна необходимо провести валидацию кода.  

• Используются инструменты, такие как SonarQube, для проверки качества кода.  

• Качество кода включает форматирование, соответствие стандартам и покрытие тестами.  

• Юнит-тесты проверяют правильность работы функций и модулей.  

• Покрытие тестами помогает выявить ошибки и поддерживать качество кода.  

• Уязвимости, такие как инъекции и небезопасная работа с памятью, также проверяются.  

• GitLint проверяет наличие подозрительных файлов.  

• SonarQube используется для оркестрации пайплайнов и создания полити-гейтов.  

• Полити-гейты блокируют дальнейшие шаги пайплайна при нарушении качества кода.  

• После валидации кода собирается артефакт и контейнерный образ.  

• Образ проверяется на уязвимости и секреты.  

• При обнаружении уязвимостей задача отправляется на доработку.  

• Docker Build используется для сборки образов, но имеет проблемы с кэшированием.  

• Buildx предлагает улучшенную сборку и кэширование.  

• Canicula работает в пользовательском пространстве и имеет свои ограничения.  

• Flant и другие инструменты предлагают комплексные решения для сборки и доставки.  

• Важно выбирать инструменты, которые поддерживаются и развиваются.  

• Использование популярных инструментов помогает избежать проблем и делиться опытом.  

• Образы можно хранить в Gitlab, GitHub или специализированных хранилищах.  

• Артефакторы и Nexus предлагают универсальные решения.  

• В облачных средах, таких как Amazon и Google, есть свои контейнерные репозитории.  

• Версионирование должно учитывать уникальные особенности каждой организации.  

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

• Мобильная разработка имеет свои уникальные правила публикации.  

• Фронтендеры сталкиваются с трудностями из-за необходимости обогащать артефакты на каждом этапе.  

• Важно минимизировать изменения артефактов, чтобы избежать конфликтов.  

• Контент собирается под каждое окружение отдельно, что требует стратегии версионирования.  

• Календарь версионирования: привязка версии к дате релиза.  

• Семантик версионирование: разделение версий на мейджер, минор и патч.  

• Семантик версионирование обеспечивает совместимость и обратную совместимость.  

• После версионирования необходимо запустить тесты, включая интеграционные.  

• Пирамида тестирования: разделение тестов на быстрые и медленные.  

• Деплой зависит от языка программирования, артефактов и целевой платформы.  

• Деплой может происходить на разные платформы: виртуальные машины, Kubernetes, облака, мобильные приложения.  

• Важно задавать наводящие вопросы на собеседованиях для понимания стратегий деплоя.  

• Роллинг апдейт: замена старых реплик новыми.  

• Грин блю или ред блэк: полное переключение трафика на новую версию.  

• Канареечный деплой: постепенное увеличение трафика на новую версию с возможностью отката.  

• Использование системы мониторинга для выявления ошибок.  

• Откат к старой версии при увеличении количества ошибок.  

• Канареечный деплой как аналог шахтерской канарейки для выявления опасных условий.  

• Об тестирование: скрытое тестирование с использованием инструментов, таких как флагер.  

• Бизнес-эксперименты: проведение экспериментов аналитиками с использованием инструментов, таких как гроссбук.  

• Различные подходы к интеграционному тестированию: использование докер-компо, селениум, синоид.  

• Перфоманс тестирование: проверка производительности и устойчивости системы к нагрузке.  

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

• Использование утилит, таких как AB Apache Bench и Яндекс Танк, для создания нагрузки.  

• Автоматические скейллеры для масштабирования системы при увеличении нагрузки.  

• Для нормального перформанса нужны генератор нагрузки и система мониторинга.  

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

• Мониторинг помогает обеспечить масштабирование приложения.  

• Тестирование может упираться в производительность базы данных.  

• Важно изолировать компоненты системы для точного тестирования.  

• Задачи тестирования могут быть разными: определение пределов ресурсов или боксирование приложения.  

• DevOps-инженеры предоставляют скелет пайплайна для расширения другими командами.  

• DevOps должны обладать широкими знаниями, но не заниматься ручными тестами.  

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

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

• В стартапах можно использовать решения, проверенные сообществом.  

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

• Вопросы о пайплайне: линтеры, сборка артефакта, проверка, деплой, тестирование.  

• Вопросы о статусе диплоя через вебхуки и мерч-квесты.  

• Вопросы о динамическом диплое и работе с пиар-марами.  

• Работа с пиар-марами позволяет гибко управлять объектами.  

• Возможность использования меток и команд для автоматизации.  

• Вопрос о гитопс для приватных облаков и его ограничениях.  

• Обсуждение отсутствия готовых решений для билдинга приватных облаков.  

• Использование самописных решений и доработок.  

• Важность мониторинга для выявления проблем с утилизацией ресурсов.  

• Важность договоренности с разработчиками о стратегии ветвления.  

• Постоянное самообучение и самосовершенствование.  

• Обсуждение различных инструментов для CI/CD, таких как Jenkins, CircleCI и Gitlab.  

• Jenkins: простота использования, но ресурсоемкий и не масштабируемый.  

• CircleCI: интеграция с хранилищем кода, но требует дисциплины в написании кода.  

• Gitlab: концепция степа, позволяющая реализовать атомарные действия, но менее гибкая.  

• Преимущества таймс-стемпа перед семивер: монотонное увеличение времени.  

• Использование дополнительного ключа для идентификации сборок.  

• Экономия времени на отладку и понимание системы.  

• Обсуждение идеального пайплайна для отсева неподходящих кандидатов.  

• Важность обучения и поддержки новых сотрудников.  

• Завершение видео с благодарностью зрителям и участникам.