В Bazel есть две крайне полезные фичи: stamping — позволяет встроить в артефакт данные о том, от какого коммита можно собрать аналогичный артефакт и remote cache и remote build — позволяет иметь общий кэш между сборщиками или даже собрать артефакты на ферме.

Ранее, к сожалению, эти фичи были взаимоисключающими, но с версии Bazel 7.0 можно использовать stamping с remote cache при помощи scrubbing-а. А сегодня вышла версия Bazel 7.1, в которой появилась возможность использовать stamping с remote build.

Я не нашел в документации к Jenkins утверждения, что Jenkinsfile пишется на Groovy, но количество отсылок к Groovy столь велико, что у многих людей создаются ложные ожидания.

Я решил написать этот пост после многократного объяснения коллегам отличий скрипта Jenkinsfile от Groovy.

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

С некоторыми ошибками мы пишем в лог стек вызовов. Используемая нами IDE (Idea, GoLand) позволяет по скопированному стеку вызовов получить комфортную навигацию по файлам (Analyze external stack traces). К сожалению, эта возможность хорошо работает только в том случае, если бинарый файл собран на том же хосте, на котором запущена IDE.

Этот пост посвящён тому, как мы пытались подружить формат стека вызовов и IDE.

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

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

Разберемся, как stamping использовать...

При поиске решений для сборки больших проектов на Go с завидной регулярностью попадались отсылки на статьи про Bazel.

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

Это первый пост из цикла, посвященного миграции с go build на Bazel.

К процессу миграции мы подошли на этапе, когда запуск тестов на CI занимал примерно от 15 минут до часа. При этом мы уже успели реализовать некоторое распараллеливание и кэширование результатов тестов. Без этого тесты на одной машине должны были бы идти примерно часов восемь.

После внедрения Bazel запуск тестов на CI в основном укладывается в интервал от 1,5 до 25 минут (50 перцентиль в районе 12 минут), что гораздо комфортнее исходной ситуации.

Оговоримся, что сравнение этих цифр «в лоб» несколько некорректно: с одной стороны, за время пути кодовая база стала еще больше, а с другой – поменялась топология CI. Но в целом представление о полученном эффекте они дают.

Далее опишем, за счет какого механизма достигнуто ускорение.

Скоро выходит версия Go 1.18, и в массовом сознании она, скорее всего, будет ассоциироваться с Generic-ами. Но помимо них туда попадает еще несколько вкусных фичей. Например, Go Workspaces.

Мы собираем зависимости для нашего тестового окружения в Docker-образ, что оказалось очень удобно. Но недавно у нас появился разработчик с MacBook M1, и резко встал вопрос о возможности поддержки двух платформ.

Мы столкнулись с достаточно занятным поведением при работе с Headless-сервисом в Kubernetes. В нашем случае проблема возникла с mongos, но она актуальна для любого Headless-сервиса. Приглашаю вас почитать нашу историю и самим попробовать поиграться с этой проблемой локально.

На одном из проектов мы используем MongoDB и Kubernetes. У MongoDB есть компонент: mongos. Через него выполняются запросы в шардированном MongoDB кластере (можно считать, что это просто хитрый proxy). До переезда в Kubernetes сервисы mongos устанавливались непосредственно на каждый хост.

При переезде сервисов в Kubernetes мы поселили пул mongos в Headless-сервис с автоматическим масштабированием Deployment через HPA (Horizontal Pod Autoscaler).

Через некоторое время выяснилось, что приложению при уменьшении количества Pod с mongos становится не очень хорошо.

1. Единственный плюс IPv6 — практически безграничное адресное пространство;
2. IP-адресов мало, но, так как большинству белый адрес не нужен, нас спасет NAT;
3. Если «отжать» IP-адреса у компаний, получивших большие пулы на заре интернета, то хватит еще на несколько лет.