На этот раз мы с радостью объявляем о релизе GitLab 16.7 с фичей GitLab Duo Code Suggestions в общем доступе, бета-версией каталога CI/CD, новым детальным представлением графиков отчётов Insights, результатами сканирования SAST в представлении изменений мерж-реквеста и многими другими фичами!
Мы все были там: Вы работали над множеством изменений одновременно, некоторые из которых не имели ничего общего. Для удобства вы решили объединить все эти изменения в один коммит и на этом закончить. Но хотя это может показаться заманчивым, на самом деле это может привести к большим проблемам в дальнейшем. Большие коммиты могут:
Сегодня мы с радостью объявляем о релизе GitLab 16.6 с бета-версией GitLab Duo Chat, правилами соответствия требованиям на основе подтверждения мерж-реквестов, улучшенным механизмом ветвления, улучшенным интерфейсом пользователя для управления переменными CI/CD и многими другими фичами!
При построении релизного цикла приходится балансировать между двумя крайностями. С одной стороны, хочется по максимуму отлавливать баги и дотошно проверять каждый релиз. С другой — быстрее выпускать обновления и приносить клиентам больше пользы.
Мы в Mindbox долго решали это противоречие и, кажется, добились баланса: презентуем несколько релизов в день и каждый проходит несколько этапов проверки, чтобы баги не дошли до клиентов. Пайплайн удобен и для команды: больше сотни разработчиков работают одновременно и не блокируют действия друг друга, а обновления происходят автоматически.
О том, какой путь проходит релиз и какие инструменты обеспечивают его надежность, расскажет engineering manager Mindbox, Бадал.
Иногда бывает так, что вы отправляете на проверку пул-реквест, который оказался существенно больше, чем вы ожидали. И у вас возникает вопрос:
«Какого же размера он должен быть? Бывает ли идеальный размер? Если бы теоретически можно было полностью его контролировать, то насколько большим его нужно делать?»
Вы гуглите, находите множество ресурсов, сайтов и статей наподобие этой, которые анализируют тему и делают примерно такой вывод:
«Слишком маленькое количество строк может не отображать полностью изменения, а чрезмерно большой PR может утомить проверяющих, что усложнит выявление проблем или написание осмысленного отзыва»
И хотя вы понимаете логику автора, в то же время осознаёте, то теоретический ответ может быть лишь смутным, что «серебряной пули» не существует. Как всегда, в жизни всё сложнее.
Однако моя статья будет немного о другом:
«Мы проанализируем PR примерно 30 тысяч разработчиков, чтобы проверить, как размер PR коррелирует с временем внедрения, полученными комментариями и отказами во внесении изменений, чтобы найти статистически наилучший размер и понять, что на него влияет.»
Пояснение: тем, кто экспериментирует с данными, особенно после прохождения курсов/обучения в сфере данных, приведённое выше может напомнить о фразе «Корреляция не означает причинно-следственной связи». Да, они будут абсолютно правы. Мы попытаемся рассмотреть под разными углами, как эта корреляция варьируется в зависимости от компании, разработчика и общего объёма коммитов кода, а также под другими углами, которые могут помочь нам понять, какие другие значения могут по каким-то причинам отвечать соответствующим паттернам. Однако это «всего лишь» числа и корреляции, они не объясняют своих причин, поэтому любые наши предположения о причинах, скорее, субъективны и не подтверждены научными исследованиями.
Мы с радостью объявляем о релизе GitLab 16.5 с отчётами о соблюдении стандартов соответствия требованиям, правилами задания целевой ветки мерж-реквеста, возможностью завершать обсуждения по тикету, ускорением цепочек мерж-реквестов для полулинейной истории коммитов и многими другими фичами!
Сегодня мы с радостью объявляем о релизе GitLab 16.4 с настраиваемыми ролями, списком зависимостей для групп и подгрупп, локальному доступу к кластерам при помощи учётных данных GitLab, рабочими пространствами для приватных проектов и многими другими фичами!
Git - одна из наиболее популярных систем контроля версий, используемых разработчиками по всему миру. Однако, существует множество различных подходов к организации рабочего процесса с использованием Git. В этой статье мы рассмотрим некоторые из наиболее популярных методов, такие как Git Flow, Trunk-Based Development (TBD), на их основе бизируются остальные:
Привет Хабр, меня зовут Дмитрий Несмеянов, я являюсь руководителем направления разработки ML-инфраструктуры "ЛОКО-банка".
Сегодня я хочу рассказать про DVC: инструмент, который многие, незаслуженно, обходят стороной. Была хорошая статья от Райффайзен Банк, в этой статье я постараюсь резюмировать мою и коллег экспертизу в работе с DVC.
DVC (Data Version Control) - это система версионирования датасетов и не только, которая является надстройкой над git. Если вы умеете работать с git, поздравляю, вы умеете работать с DVC. Кроме того, DVC позволяет логировать эксперименты, а также делать Auto-ML.
Из уст переводчика: инструмент puro совсем новый по меркам продуктовой разработки (первый релиз – октябрь 2022), но, по моему личному мнению, api его уже достаточно стабилизирован, а сам инструмент выражает искреннюю радость подходами. Большинство его текущих преимуществ (и выгодных отличий от fvm) я разбирал ранее в этом исчерпывающем материале – "Полное руководство по использованию FVM (Flutter Version Management) – жонглируйте версиями Flutter sdk в своих проектаx" – где вполне наглядно показано торжество puro...
В жизни разработчика рано или поздно наступает момент, когда проектов становится так много, что одной единственной (обычно это stable) версией flutter sdk уже не обойтись. В данной статье мы рассмотрим консольный инструмент fvm для управления версиями flutter sdk, ВСЕ имеющиеся в нём команды и пройдём путь от установки до использования в проекте.
В качестве бонусных аспектов я также уделил время на изучение Sidekick (графическая оболочка для fvm) и на разбор имеющихся аналогов (Puro – сильно уверен, что вы не слышали о таком инструменте).
Прошу к изучению 🧐
Это практическое дополнение к моей предыдущей статье, где я рассказывал, почему вам может быть интересен способ ведения версий с помощью бранчей. Сейчас же я хотел подробнее показать, как это можно реализовать на примере одного сценария. Естественно, я не могу показывать свои реальные юзер флоу, поэтому предположим, что у нас есть большой сценарий, за развитие которого вы отвечаете.
Сегодня мы с радостью объявляем о релизе GitLab 16.2 c совершенно новым редактором текста, палитрой команд, поддержкой подписей без ключей с Cosign, новым уровнем настроек для панели аналитики разработки и многими другими фичами!
Актуальность конфигурационных файлов – основа основ стабильной работы сети и активного оборудования. Раньше конфигурационные файлы можно было просто копировать автоматизированным способом при помощи специальной утилиты, и этого вполне хватало для успешного восстановления после замены вышедшего из строя оборудования. Но появились новые задачи, это связано с тем, что многие вендоры начали развивать технологию Infrastructure as Code (IaC).
То есть, можно описать свои действия с устройством с помощью кода, а затем его применить, а не использовать интерфейс командной строки или GUI интерфейс. Это существенно уменьшает вероятность ошибки при каких-либо манипуляциях при управлении устройством. В связи с этим возникла другая задача – как отслеживать актуальность и историю изменений в данном коде. Центр информационных технологий РТ стал использовать систему контроля версий, так же как её используют большинство программистов.
Сегодня речь пойдет про Git.
Что такое «система контроля версий» и почему это важно? Система контроля версий – это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая позже вернуться к определённой версии.
Сам Git является распределенной системой контроля версий (Distributed Version Control System, далее DVCS). В DVCS клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) – они полностью копируют репозиторий. В этом случае, если один из серверов, через который разработчики обменивались данными, умрёт, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Каждая копия репозитория является полным бэкапом всех данных.
Всем привет! Меня зовут Маша, и я Golang Backend Developer в компании Ozon. В этой статье я хотела бы поговорить о теме, так или иначе объединяющую все сферы нашего любимого мира IT. А именно — VCS Git.
Без системы контроля версий сейчас невозможно представить ни один проект. Это оплот любой кодовой базы, это мощнейший инструмент, с помощью которого эту базу можно изменять и отслеживать. Однако нередко чистотой истории изменений пренебрегают, полагаясь на старое доброе «И так сойдёт!», абсолютно игнорируя при этом сложность понимания и поддержки такой истории в будущем.
В этой статье я рассмотрю причины такого подхода, его недостатки, а также способы решения проблем, к которым он приводит. Я выделила несколько основных принципов, которые помогут прийти к чистой истории изменений проекта. Давайте же вместе исследуем эту темную, неизведанную сторону Git, которая нам в этом поможет.
Сегодня мы с радостью объявляем о новом релизе GitLab 16.1 с полностью изменившимся опытом навигации, GitLab Dedicated в общем доступе, визуализацией ресурсов Kubernetes, аутентификацией через сервисные аккаунты и многими другими фичами!
В статье я рассказываю, как в репозитории веб-сервиса «GitHub» можно переименовать сразу множество файлов одним коммитом.
У меня небольшой учебный репозиторий, с которым я работаю через веб-интерфейс. Через веб-интерфейс можно переименовывать файлы по одиночке, но иногда появляется необходимость переименовать сразу много файлов по одному и тому же принципу. Операция переименования состоит из нескольких этапов: клонирование репозитория на свой компьютер, написание скрипта для переименования множества файлов и запуск переименования, создание коммита и отправка изменений в оригинальный репозиторий на «GitHub».
По ходу дела я касаюсь работы с «Git» из командной строки, немного разбираю настройку Git-репозитория, пишу скрипт на языке PowerShell, работаю с регулярными выражениями и создаю гранулированный токен доступа в «GitHub».
Хранилища кода являются неотъемлемой частью современной разработки ПО. Они позволяют командам разработчиков управлять своим кодом, устанавливать версии и совершенствовать процесс разработки. Современные реалии внесли свои коррективы в работу, заставив в короткие сроки перейти на российские аналоги ПО.
В статье Центр цифровой трансформации РТ рассказывает о своем опыте импортозамещения платформы Bitbucket на отечественный софт, о выявленных плюсах и минусах, и о сделанных выводах.
Привет, Хабр, Я QA инженер в команде интеграции. Моя команда интегрирует локальных платежных провайдеров, чтобы наши клиенты могли заводить и выводить деньги. Из-за большого количество провайдеров у нас возникла проблема с деплоем сервисов на нужную ветку для тестирования. В этой статье, я представлю наше решение этой проблемы в виде Slack бота и не только. Надеюсь, кому-то это тоже поможет решить подобную проблему.
Разработчикам несомненно надо уметь работать с Git и делать это через командную строку. Иногда бывают ситуации, когда просто нет возможности установить на машину альтернативный инструмент с графическим интерфейсом. При этом некоторые задачи удобнее выполнять в специализированных приложениях, и никто не запрещает использовать GUI в собственных проектах.
В этой статье собраны самые популярные графические интерфейсы Git. Есть как бесплатные инструменты с открытым исходным кодом, так и проприетарные решения с дорогими лицензиями. Некоторыми клиентами из статьи я пользовался сам, чтобы в итоге выбрать удобный вариант для своих задач.
