Git *

Привет! Меня зовут Максим, я руковожу мобильной разработкой в 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. Самый быстрый вариант — менять сразу на проде. Но если вносить изменения в такие справочники без тестирования, то в случае ошибки рискуешь получить страховки с комиссией в разы больше или меньше нужной, да ещё полный сбой оформления кредитных заявок.

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

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

На рынке доступно множество инструментов непрерывной интеграции и непрерывного развёртывания. Эти инструменты играют ведущую роль в координации и автоматизации работы на различных этапах CI/CD-пайплайна.

Мы пообщались с Александром Довнаром, Lead DevOps в Naviteq, и узнали, как безопасность проекта связана с выбором CI/CD-инструмента. Подробно остановились на том, что такое GitLab CI, кому он подходит и почему его стоит использовать. 

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

В статье рассматривается ситуация, когда необходимо синхронизировать два репозитория, находящихся на изолированных друг от друга серверах Gitlab, и есть машина, с которой есть доступ до обоих серверов. Синхронизация осуществляется скриптом на bash, который проверяет наличие обновлений и производит pull-push при их наличии, а также оповещает о событии в Telegram.

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

Обычно в тестирование начинают вкладываться, когда багов становится слишком много, недовольство клиентов растёт, и начинают «гореть» деньги бизнеса. Вместе с Александром Довнаром, Lead DevOps в Naviteq, мы разобрали, что такое непрерывное тестирование и какую роль оно занимает в CI/CD. А ещё рассмотрели кейс, как компании приходят к его внедрению, и что это внедрение даёт. 

Наконец-то я "раздобыл" немного свободного времени, а значит пришла пора продолжить серию туториалов по XWiki.

После публикации одной из моих статей MaxK82 спросил у меня, можно ли как-то в XWiki подключить документацию из git репозитория, так чтобы наладить её версионирование. К сожалению эта статья не ответит на его вопрос, но возможно укажет направление, в котором стоит "копать".

Поэтому сегодня мы с вами:

- создадим простенький, но зато свой макрос в XWiki;

- клонируем прямо в XWiki репозиторий с GitLab;

- отобразим Readme.md из репозитория внутри страницы XWiki.

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

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

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

Эта статья предназначена для тех, кто уже имеет начальный уровень работы с GIT и BitBucket. В статье рассматриваются примеры в Git Bash version 2.33.0, API BitBucket 2.0, https://bitbucket.org

Смотри, ты устроился работать в большую компанию, где много команд, каждая разрабатывает свой продукт, часть из них создаёт микросервисы вокруг ядра, часть создаёт свои отдельные полноценные продукты. И, допустим, вся разработка до сих пор не использует централизованное хранение кода, работает без CI/CD и без наработок DevOps. Твоей первой задачей поставили организовать подход к хранению исходного кода в рамках всей компании. По секрету скажу, большие компании любят, когда используется единый подход, индивидуализм для бизнес-конвейеров всегда означает сложность управления сроками разработки, поставки и т.д. Задача, которая кажется простой на первый взгляд, всегда обрастает сложностями в нюансах.

Ты настроен на волну NotOps и в этой статье я постараюсь ответить на вопросы:

В результате приостановки работы зарубежных компаний и отключения российских компаний от платежных систем Visa и MasterCard многие программисты столкнулись с проблемой доступа к привычным сервисам. Рассказываем о бесплатных альтернативах продуктам, которые уже недоступны для российских пользователей по корпоративным подпискам или могут стать такими в ближайшее время.

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

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

Автор книг Dependency Injection in .NET («Внедрение зависимостей на платформе .NET») и Code That Fits in Your Head рассказывает о своём подходе к Git и git stash, позволяющем добиться большой гибкости в работе с кодом. Опытом Марка Симана делимся к старту курса по разработке на С#.

Маленькой команде не составляет труда поддерживать историю изменений приложения в ручном режиме. Но, когда команда начинает расширяться, такой файл как changelog, находящийся в системе контроля версий, становится «узким горлышком» и приводит к постоянным конфликтам и росту напряжения в команде.

На помощь, как всегда, приходит автоматизация. Если интересно узнать о том, как автоматизировать генерацию changelog в gradle проекте, добро пожаловать под кат.