home.social

#ci-cd — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #ci-cd, aggregated by home.social.

fetched live
  1. CI/CD в эпоху агентов

    С интересом наблюдаю, как инженерные процессы и инструменты, к которым мы привыкли за десятки лет, переосмысливаются под ИИ-нативный подход. Например, классический CI/CD, построенный вокруг pull request-ов и человеческого темпа разработки, плохо подходит для мира, где код всё чаще пишут агенты. До работы с агентами цикл разработки выглядел так: человек медленно пишет код → оформляет PR → CI прогоняет линтеры, тесты и сборку → другой человек ревьюит изменения → изменения попадают в основную ветку. В такой парадигме долгое время работы CI-пайплайна часто было ожидаемым и терпимым, потому что самая большая задержка всё равно была на стороне команды: разработчик писал код часами или днями, ревью тоже ждали часами или днями, PR жил долго. С агентами всё меняется: код генерируется быстро и относительно дёшево → задач становится больше → ветки с изменениями плодятся быстрее → PR становится слишком медленной и неудобной единицей работы → валидацию изменений нужно двигать внутрь агентного цикла. Но CI/CD вряд ли не исчезает. Скорее он перестанет быть контуром вокруг которого происходит работа с изменениями и превратится в низкоуровневый слой для быстрой проверки изменений внутри агентного цикла. Почему так? CI/CD в текущем виде был спроектирован для мира, где человек — главный агент. Человек держит в голове некое намерение: например, «хочу добавить кнопку оформления заказа». Потом проходит цикл: намерение → код → pull request → CI → код-ревью → merge. На каждом этапе может быть откат назад:

    habr.com/ru/articles/1034948/

    #cicd #sdlc #ииагенты_для_разработки

  2. Does anyone know if there's an equivalent to "GitLab Components" in Forgejo?

    #forgejo #Gitlab #CICD #Devops #Devsecops

  3. GitLab should look into Zuul

    The evolution of GitLab reminded me of Zuul, built to handle multiple merge requests in parallel "at a rate no human team ever did". Machine-scale infrastructure. Agents open merge requests in parallel, trigger pipelines around the clock, and push commits at a rate no human team ever did. Source: GitLab Act 2

    maffulli.net/2026/05/13/gitlab

  4. AI Review не делает код лучше. И вот почему

    Я делал AI Review как простой инженерный инструмент. Но реальный фейл оказался не в архитектуре и не в LLM — а в том, чего люди от него ждали.

    habr.com/ru/articles/979862/

    #ai_review #code_review #llm #cicd #chatgpt #claude #gemini #openrouter #gitlab #github

  5. 「 The entire tech stack of your Fortune 500 company, the platform generating millions in revenue, depends on infrastructure maintained by non-profits that are barely getting by on donations 」
    phpunit.expert/articles/open-s

    #opensource #packagemanagment #cicd

  6. Без рук: автоматизируем нагрузочное тестирование изменений в CI

    Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова. Почему команды не тащат нагрузку в релизный цикл? Потому что это чаще всего просто не окупается: нужно выбрать движок, описать сценарий, гонять тесты вручную или тратить время на создание собственной обвязки для встраивания в CI, придумать критерии качества и анализировать результаты. Всё это занимает значительное время, а на короткой дистанции часто оказывается оверинжинирингом. Но если формирование требований упростить концептуально невозможно, то всё остальное вполне можно собрать в переиспользуемый инструмент, позволяющий командам легко интегрировать нагрузочное тестирование и регрессионный анализ в свой процесс доставки. В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе. Посмотрим, к чему мы в итоге пришли.

    habr.com/ru/articles/1033590/

    #нагрузочное_тестирование #регрессионное_тестирование #locust #devops #locomotive #python #github_actions #performance_testing #cicd #производительность

  7. Хватит копировать security YAML: AppSec-слой для Java-проектов через Gradle convention plugin

    Практический разбор того, как я вынес security-проверки Java-проектов из разрозненных CI/CD-скриптов в переиспользуемый Gradle plugin

    habr.com/ru/articles/1032532/

    #cicd #gitlabci #java #gradle #gradleplugin #security #sast #sbom

  8. Как сделать Maven build security-aware: AppSec-проверки без дрейфа CI/CD

    Единый плагин для сканирования на безопасность Java проектов. Maven. Или как проверять кучу микросервисов на безопасность управляя этим в одном месте Скачать плагин

    habr.com/ru/articles/1032514/

    #java #плагин #cicd #gitlabci #sast

  9. 200 OK по протоколу, но не OK для клиента: автоматизация контроля совместимости API и приложения

    Выпустить релиз — часы работы команды. Упасть на старте — 1 секунда. Узнать об этом не из отзывов пользователей — бесценно. Серверные тесты проходят, эндпоинт отвечает 200 OK, но мобильный клиент падает на первом же ответе API. Типичный сценарий: в user.id приходит null , у status появляется новое значение или меняется вложенная структура — и ответ API расходится с клиентскими моделями. Чтобы ловить такие расхождения до релиза, мы встроили в пайплайн контроль совместимости API и приложения. Этот слой решает две задачи: не даёт серверным изменениям ломать текущий клиент и проверяет совместимость предстоящего релиза с текущим бэкендом. При расхождении пайплайн останавливается на этапе проверки api, до build/archive/sign/publish. Я Алексей Матвеев, директор по мобильным технологиям в «Первой Форме». В статье расскажу, как мы задали архитектуру решения и делегировали ИИ рутинные задачи. В CI/CD мы проверяем ответы API по DTO и YAML-контрактам, а для сценариев изменения состояния сверяем «до/после». Итог сразу уходит в CI-лог и тред задачи.

    habr.com/ru/companies/1forma/a

    #мобильная_разработка #api_тестирование #cicd #devops #ai #llm #bpmсистемы #автоматизация #корпоративные_приложения