Git *

Спикер курса «CI/CD на примере Gitlab CI», Lead DevOps в Naviteq (ex. Onesoil and EPAM) Александр Довнар, рассказывает про CI, CD и еще раз CD.

Александр — AWS Community builder и сертифицированный архитектор, соведущий подкаста DevOps Kitchen Talks. 11+ лет работает в IT и сетях, из них 7+ лет — в Devops.

Эта статья — расшифровка вебинара, где Александр рассказывает, что за зверь CI/CD, кому и когда он нужен и зачем применять его в команде, а также обсуждает текущие проблемы индустрии вокруг этой практики.

Можно ли с помощью GitHub анализировать работу, не заглядывая в монитор сотрудника — без скриншотов и тайм-трекеров?

Я Александр Кириллов, технический директор компании Evrone. Больше 20 лет я посвятил разработке. В этой статье поделюсь с вами опытом, который собрал за время работы с распределенными командами. Расскажу о том, как, не нарушая приватность разработчиков, следить за качеством работы на проектах и отслеживать нежелательные паттерны с помощью метрик в Jira и Git.

Как бы мы себя не обманывали - Размер имеет значение! И конечно, мы будем говорить о размере нашего андроид приложения, куда мы добавляем кучу классных features, и даже не задумываемся как это может негативно повлиять на размер приложения. Поэтому мы научимся обнаруживать регрессию размера нашего приложения на CI для автоматизации этого процесса.

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

На самом деле почти никто не знает, что такое GitOps. Я тоже заблуждался, пока не начал готовить доклад, а потом статью по этой теме. Самое распространенное определение GitOps — это «хранение состояния в Git», но оно не единственное и не самое главное. Это звучное словечко  придумали в Weaveworks, но его название несколько разнится с его реальным пониманием. Созвучие с DevOps — скорее, маркетинговый ход, чем реальное отражение сущности. Основная идея GitOps в том, что помимо хранения состояния в Git, у нас есть непрерывный процесс его синхронизации с реальным миром, то есть, что у вас Kubernetes-кластере или где либо ещё в вашем окружении.

Меня зовут Андрей Квапил. Я работал в чешском хостинге WEDOS. Он не сильно популярен в России, но это крупнейший хостинг на территории Чехии (просто Чехия маленькая).  Сейчас я работаю во Фланте, но именно на примере европейского хостинга WEDOS, хочу рассказать историю имплементации GitOps.

Как бы мы себя не обманывали - Размер имеет значение! И конечно, мы будем говорить о размере нашего андроид приложения, куда мы добавляем кучу классных features, и даже не задумываемся как это может негативно повлиять на размер приложения. Поэтому мы научимся обнаруживать регрессию размера нашего приложения на CI для автоматизации этого процесса.

В данной части, обсудим как можно проверять размер в pull request, что позволит автоматизировать весь процесс обнаружения регрессии, до того как изменения попали в development.

Как бы мы себя не обманывали - Размер имеет значение! И конечно, мы будем говорить о размере нашего андроид приложения, куда мы добавляем кучу классных features, и даже не задумываемся как это может негативно повлиять на размер приложения. Поэтому мы научимся обнаруживать регрессию размера нашего приложения на CI для автоматизации этого процесса. В данной части, обсудим как можно легко проверять размер в development ветке.

В прошлое воскресенье 4 сентября я обнаружил, что GitHub-организация DigitalDesignSchool, в которой я являюсь одним из владельцев, забанена Гитхабом с формулировкой "ваш аккаунт может быть предметом американских экономических санкций".

Пораскинув мозгами и посовещавшись с моим приятелем, основателем московского интернет-провайтера RiNet Сергеем Рыжковым, у которого в тот же день забанили счет в Ситибанке в Лондоне, я решил: нужно бороться.

Привет! Меня зовут Павел Лакосников, я тимлид команды бэкенд-инженеров в Авито. Сегодня расскажу про свой любимый подход к разработке Trunk Base Development, сравню его с другими моделями ветвления и подсвечу его достоинства и нюансы.

Краткий обзор трёх моделей ветвления: Central Workflow, Git Flow, Trunk Based Flow, с акцентом на моего фаворита — Trunk Based Flow.

Вы написали тестовое, выложили на гитхаб и обратно спуллили. А оно не работает.

На связи Саша Хрущев, технический директор IT-компании WINFOX. Рассказываю, как мы быстренько развернули свое независимое локальное хранилище репозиториев в GitLab CE, сколько времени это заняло и какие особенности вам нужно учитывать при переезде, чтобы все прошло гладко. 

Как настроить пайплайн сборки с помощью K8s + Gitlab + Werf за 30 минут и больше не мучаться. Мини-туториал по настройке окружения с примером.

Привет! Меня зовут Максим, я руковожу мобильной разработкой в KTS.

Наша команда мобильной разработки использовала Upsource с 2017 года: на тот момент он был одним из самых удобных инструментов для просмотра кода, комментирования и изучения правок. Мы использовали selfhosted-вариант сервиса. 

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

Рассказываю о нашем опыте работы с системами код-ревью, и почему через 5 лет работы на Upsource мы переехали на GitLab.

Наблюдаемость (observability) — это супермножество мониторинга. В дополнение к подробному анализу неявных состояний, приводящих к сбоям, это свойство предполагает высокоуровневый обзор работоспособности системы. Кроме того, наблюдаемая система предоставляет подробную информацию о своей внутренней работе, что позволяет обнаруживать более глубокие системные проблемы.

27 июня вышел Git 2.37 с новым механизмом очистки файловой системы, её встроенным монитором и другими доработками. Подробности рассказываем к старту курса по Fullstack разработке на Python.

Всем привет! Предлагаю взглянуть на проблему, связанную с возникновением коммитов от «неизвестных» пользователей в вашем git репозитории. Такое может возникнуть, если один разработчик будет использовать несколько разных git конфигов. Расскажу, какие есть варианты избежать похожую ситуацию.

В наиболее популярном случае иметь множество инсталляций GitLab — это антипаттерн. Однако обстоятельства бывают разными: специализация нашего бизнеса привела к тому, что мы администрируем десятки self-hosted GitLab-инстансов обслуживаемых клиентов. Периодически у нас возникает потребность проделать какие-то действия на всех GitLab’ах сразу, чтобы не тратить время на многократное повторение рутинных операций. Все началось с необходимости мониторинга за критическими обновлениями для GitLab. Но аппетиты росли: со временем нам уже хотелось искать по содержимому файлов во всех инсталляциях или даже создавать пользователей.

Расскажем о том, как мы решили эти задачи в рамках внутренней разработки, которую теперь публикуем как Open Source-проект под названием glaball.

Я полагаю вы уже знакомы с git. Чтобы не привело вас сюда, добро пожаловать и надеюсь найдете все, что вам необходимо знать.

Всем здравствуйте! Я расскажу о том, как решал задачу ускорения проверки merge request’ов(MR)  в нашей команде. Почему вообще это понадобилось? Потому что разработчики ленивы экономят силы и обычно не стремятся брать новые MR на проверку, либо выбирают что попроще. Так что я решил сделать бота, который для каждого MR автоматически расставлял бы приоритеты и назначал проверяющего.

Нередкая ситуация: бизнес хочет быстро вносить изменения в такие справочники, как продуктовый каталог и тарифы. Уровень критичности этих справочников — mission/business critical. Самый быстрый вариант — менять сразу на проде. Но если вносить изменения в такие справочники без тестирования, то в случае ошибки рискуешь получить страховки с комиссией в разы больше или меньше нужной, да ещё полный сбой оформления кредитных заявок.

Я посвятил этот пост проблеме бизнес-справочников и предложил несколько вариантов решения, проверенных на котиках на себе. Под катом вас ждут максимум конкретики и программный код С#.

<Погрузиться в изменчивый мир бизнес-справочников/>