Рубрика «continuous integration»

Поддержка огромной кодовой базы с одновременным обеспечением высокой производительности большого числа разработчиков — это серьезный вызов. В течение последних 5 лет в Яндексе идет разработка особой системы непрерывной интеграции. В данной статье мы расскажем про масштаб кодовой базы Яндекса, про перенос разработки в единый репозиторий с trunk-based подходом к разработке, про то, какие задачи должна решать система непрерывной интеграции для эффективной работы в таких условиях.

Continuous integration в Яндексе - 1

Много лет назад в Яндексе никаких особенных правил в разработке сервисов не было: каждый отдел мог использовать любые языки, любые технологии, любые системы деплоя. И как показала практика, такая свобода не всегда помогала двигаться вперед быстрее. В то время для решения одних и тех же задач часто существовало несколько собственных или open-source разработок. С ростом компании такая экосистема работала всё хуже. При этом мы хотели остаться одним большим Яндексом, а не разделиться на множество независимых компаний, потому что это дает массу преимуществ: много людей делают одни похожие задачи, результаты их труда можно использовать повторно. Начиная от разнообразных структур данных, типа распределённых хеш-таблиц и lock-free очередей, и заканчивая множеством разного специализированного кода, который мы написали за 20 лет.

Читать полностью »

Картинка для привлечения внимания

Мы рады представить новый релиз GitLab 11.4 с долгожданными обновлениями, призванными помочь командам работать эффективнее. Большинство команд, применяющих DevOps, стремятся к сокращению времени цикла поставки. Поэтому разработчики всегда рады улучшениям, которые уменьшат количество работы и потери во времени, так как за счет этого ускоряется поставка продукта и повышаются бизнес-показатели.

Читать полностью »

В чем залог успешной настройки Continuous Delivery на проектах? Слаженная работа команд разработки, тестирования и инженеров по инфраструктуре. Спасибо, кэп, как говорится :) Но как это реализовать на практике? В этой статье поделимся нашими наработками, как это всё организовать и воплотить в жизнь.

Мы обобщили базовые основы в одну шпаргалку для себя и делимся с вами:

Опытные инженеры вряд ли узнают из статьи что-то новое, но надеемся, что начинающим специалистам эта информация пригодится.

Как организовать CI-CD на проекте: от постановки задач до настройки конвейера развертывания - 1
Читать полностью »

Почти всех новых сотрудников Яндекса поражают масштабы нагрузок, которые испытывают наши продукты. Тысячи хостов с сотнями тысяч запросов в секунду. И это только один из сервисов. При этом отвечать на запросы мы должны за доли секунды. Даже незначительное изменение в продукте может оказать существенное влияние на производительность, поэтому важно тестировать и оценивать влияние своего кода на сервис.

В нашем сервисе рекламных технологий тестирование работает в рамках методологии Continuous integration, более подробно об организации которой мы расскажем 25 октября на мероприятии Яндекс изнутри, а сегодня мы поделимся с читателями Хабра опытом автоматизации оценки важных продуктовых метрик, связанных с производительностью сервиса. Вы узнаете, как доверить анализ машине, а не следить за ними на графиках. Поехали!

Тестирование производительности веб-сервиса в рамках Continuous Integration. Опыт Яндекса - 1

Читать полностью »

Картинка для привлечения внимания

С новым релизом GitLab 11.3 мы рады представить вам поддержку репозиториев Maven, владельцев кода (Code Owners), защищенные окружения и прогнозы для эпиков. Все это поможет автоматизировать управление окружениями и кодом, что позволит разработчикам на Java быть еще эффективнее.

Читать полностью »

Я думаю, нет смысла в очередной раз рекламировать замечательный инструмент для статического анализа — PVS Studio. На хабре уже немало статей ей посвящённых, но я хочу коснуться ещё одного аспекта — использование данного инструмента в системе непрерывной интеграции.

Читать полностью »

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

В наших решениях мы используем интеграцию и с помощью Kafka, и с помощью gRPC, и с помощью RabbitMQ.

В этой статье мы поделимся нашим опытом кластеризации RabbitMQ, ноды которого размещены в Kubernetes.

image

До RabbitMQ версии 3.7 его кластеризация в K8S была не очень тривиальной задачей, со множеством хаков и не очень красивых решений. В версии 3.6 использовался autocluster плагин из RabbitMQ Community. А в 3.7 появился Kubernetes Peer Discovery Backend. Он встроен плагином в базовую поставку RabbitMQ и не требует отдельной сборки и установки.

Мы опишем итоговую конфигурацию целиком, попутно комментируя происходящее.
Читать полностью »

image

В GitLab 11.1 мы улучшили отображение безопасности за счёт панелей, усовершенствовали поиск по коду для своевременного получения нужной информации, внесли изменения в UX и многое другое.

Читать полностью »

Настраиваем удобный npm проект для себя и команды или немного о современных фронтенд инструментах - 1

Всем привет. Недавно мне попалась задача настроить оборот приватных npm пакетов. Все звучало очень интересно и многообещающе пока не оказалось, что делать там совсем не много. Тут бы все и закончилось, но возникла вторая задача — написать демо репозиторий для npm пакета, который можно было бы взять, клонировать и на его базе быстро создать что-то полезное и в едином стиле.

В результате получился проект с настроенным форматированием, кодстайлом, тестами на каждый пулл, лимитами на покрытие кода, отчетом о покрытии кода и автоматической документацией. Плюс удобная публикация в npm. Подробности о настройке — под катом.

Читать полностью »

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

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

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

Рецепт гладкого релиза: PMy на заметку - 1
Читать полностью »