📝 Из 2024 в 2025: вспоминаем лучшие практики CI/CD

Постепенно возвращаемся в трудовые будни. Предлагаем вспомнить best practices CI/CD прошлого года, которые, скорее всего, останутся с нами и в новом 2025 году.

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

Приятного чтения!

#Хабр #статья_Nixys #devops #cicd

⚙️ Маленькие CI/CD и большие результаты

На Reddit подняли интересную тему о различных CI/CD процессах, задав вопрос: Какие небольшие, но полезные улучшения в CI/CD вы сделали?

Собирали для вас несколько популярных ответов:

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

Напишите как можно больше CI/CD-задач в виде отдельных скриптов, чтобы можно было запускать и тестировать их локально. Но не заходите слишком далеко: написание собственной CI/CD системы на скриптовом языке — не самое лучшая трата вашего времени.

Чтобы скрипты было легко вызывать, добавьте несколько Makefiles в качестве обертки. Только эти две вещи сэкономят вам огромное количество времени.

Производительность CI/CD зависит от кэширования. В GitHub Actions есть кэш, который поддерживается Docker. Его использование значительно повышает производительность.

В этом проекте есть ряд примеров использования кэширования для оптимизации производительности. Например, использование GitHub docker реестра для обмена образами между параллельными этапами, использование кэша GitHub для файлов и т. д.

Вообще говоря, будет лучше, если вы сможете запускать CI/CD локально для дебага. Иначе вы застрянете в медленном цикле коммитов кода и ожидания сбоя CI. В этом проекте используется «контейнерная» сборка и тестирование, поэтому все, что возможно, делается в Docker. Так получается его более изолированно.

А какие CI/CD процессы посоветовали бы вы?

#devops #reddit #cicd

5 мифов о DevSecOps, из-за которых теряется скорость релизов и контроль над безопасностью

🤝Сегодня обсудим, почему DevSecOps — не про замедление, бюрократию и ещё один набор инструментов. Разберём 5 мифов, которые мешают это увидеть.

💬DevSecOps замедляет разработку
Миф: проверки безопасности добавляют фрикцию — значит, релизы будут идти медленнее.
Реальность: скорость падает не из-за DevSecOps, а из-за ручных и разрозненных проверок.
Когда безопасность встроена в CI/CD-поток (например, через автоматические SAST-, SCA- и DAST-сканеры), разработчики получают обратную связь в момент сборки или при коммите — ещё до ревью. Такая интеграция позволяет исправлять уязвимости до того, как они попадут в прод. Например, по данным Veracode, клиенты, использующие Veracode Fix, сокращают время устранения уязвимостей примерно на 92 % по сравнению с ручными подходами.

💬DevSecOps — это просто ещё один набор инструментов
Миф: купим несколько сканеров, включим проверки — и у нас DevSecOps.
Реальность: сами инструменты ничего не дают без культуры взаимодействия между разработчиками, DevOps и специалистами по безопасности. Если сканеры не интегрированы с CI/CD, issue-трекерами (например, Jira, GitLab Issues) или IDE, безопасность превращается в хаос уведомлений, которые никто не успевает обработать.

💬Разработчики должны быть экспертами по безопасности
Миф: разработчик должен стать специалистом по кибербезопасности для внедрения DevSecOps.
Реальность: грамотно выстроенный DevSecOps-процесс автоматизирует рутину и даёт понятные подсказки там, где работает разработчик — в IDE (VS Code, IntelliJ), в pull-requestах или пайплайне CI. Безопасность становится частью привычного цикла: написал код → прогнал тесты → получил подсказку по уязвимости → исправил.

💬DevSecOps не подходит малому бизнесу
Миф: DevSecOps — это история для корпораций с большими бюджетами.
Реальность: DevSecOps можно начать с малого и масштабировать по мере роста.
Даже небольшие команды могут настроить:
- SAST-проверку через бесплатные инструменты — Semgrep, SonarQube Community, Bandit;
- SCA-анализ с помощью OWASP Dependency-Check, Snyk Open Source или GitHub Dependabot.
Малый бизнес выигрывают за счёт гибкости процессов: меньше согласований, быстрее адаптация.

💬DevSecOps — это только защита от внешних атак
Миф: DevSecOps нужен только для защиты от хакеров и DDoS.
Реальность: DevSecOps охватывает всю цепочку безопасности — от конфигураций инфраструктуры до зависимостей и прав доступа.

#DevSecOps #Security #CICD #Automation

Макросы в коде: что стоит учитывать при ревью и CI/CD

👩‍💻Линус Торвальдс прошёлся по коду, где был предложен макрос make_u32_from_two_u16()— инструмент для объединения двух 16-битных чисел в одно 32-битное. На первый взгляд, решение удобно, но Линус назвал реализацию "мусорной": такая абстракция усложняет понимание и сопровождение кода.

Как улучшить код и ревью
⏺Используйте явную запись
Прямое выражение показывает порядок и логику:



((uint32_t)a << 16) | (uint32_t)b

⏺Добавляйте абстракции только при необходимости
Макросы и функции избавляют от дублирования или повышают безопасность, а не просто «упаковывают» очевидные выражения.

⏺Следите за переносимостью
Добавляйте приведения типов и маскирование, чтобы избежать ошибок на разных архитектурах:

#define MAKE_U32_FROM_TWO_U16(high, low) \
    (((uint32_t)(high) << 16) | ((uint32_t)(low) & 0xFFFF))



⏺Сохраняйте ясность и локальность изменений
Если нужна общая утилита — поместите её в отдельный модуль и документируйте назначение. Так, вы снижаете вероятность конфликтов и улучшаете читаемость кода.

⏺Используйте ИИ-инструменты осознанно
Генераторы кода (ChatGPT, Gemini и пр.) могут предложить готовое решение, но итоговый вариант важно проверять: читаемость, переносимость, соответствие стилю проекта — всё это остаётся задачей разработчика.

Даже небольшие абстракции требуют осознанного подхода.
Если операция проста, прозрачна и понятна, лучше записать её явно. Так, код становится надёжнее, ревью — быстрее, а CI/CD-процессы — стабильнее.

#DevOps #Linux #CICD