Системы управления версиями *

А есть ли жизнь вне GIT? Что там? Может там летают птеродактили или НЛО? Или там просто пустое поле? Давайте разбираться.

Привет, Хабр. Всех с наступившим Новым Годом.

На днях наткнулся на статью Махмуда Хашеми, в которой обсуждаются некоторые недостатки методологии семантического версионирования (SemVer), и в качестве решения этих недостатков предлагается использовать календарное версионирование (CalVer). В организации, где я работаю, по стандарту разработки требуется обязательно версионировать приложения по SemVer. Из собственного опыта использования SemVer скажу, что нашёл в ней ещё ряд недостатков, для исправления которых пришлось искать новый способ версионирования.

Привет! Меня зовут Егор Сизов, в компании «Цифра» (дивизион Непрерывные производства) я руковожу направлением «Системы управления производством».

За этот год, среди прочего, я занимался двумя крупными проектами: организации сбора библиотеки готовых конфигураций и конвертацией конфигураций PI System в Платформу ZIIoT. 

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

Материал будет полезен прежде всего для тимлидов внедрения, архитекторов решений и руководителей.

Когда я закончил работать над проектом ecosyste-ms/package-manager-resolvers, мне стало интересно, какой алгоритм разрешения зависимостей использует сервис GitHub Actions. Когда вы записываете в файл рабочего потока uses: actions/checkout@v4, то объявляете зависимость. GitHub её разрешает, скачивает и исполняет. Так работает управление пакетами. Я же решил отправится в кодовую базу runner, чтобы увидеть весь этот процесс изнутри. И открытия, скажу я вам, оказались весьма тревожными.

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

В каждом моём профессиональном и личном проекте рано или поздно требовался diff для визуализации изменения или применения патча. Однако меня никогда не устраивала ни одна из свободно доступных библиотек diff. В профессиональной деятельности это никогда не вызвало особых проблем, но в личных проектах я копировал и модифицировал из проекта в проект собственную библиотеку. Однажды я рассказал об этом коллеге, и тот наставил меня на путь публикации моей библиотеки на Go (порта библиотеки на C++, которую я раньше копировал и модифицировал). И оказалось, что я сильно недооценивал то, насколько близка моя библиотека к возможности публикации!

Как бы то ни было, я опубликовал её и узнал много нового об алгоритмах diff. Библиотеку можно найти по адресу znkr.io/diff, а в этой статье я расскажу о своих открытиях. Я ещё не завершил освоение, поэтому планирую дополнять статью в процессе изучения.

Тестирование — это не просто поиск ошибок. Это способ убедиться, что продукт действительно работает так, как должен, и делает жизнь пользователей проще, а не сложнее. Хорошее тестирование начинается задолго до первого нажатия кнопки “Run tests” — с понимания логики продукта, требований и рисков.

Конвейер непрерывной интеграции и поставки CI/CD является эффективным инструментом быстрого и качественного выпуска программного обеспечения. Разработчики и тестировщики активно используют те преимущества непрерывной разработки, которые дает данный пайплайн. Но экосистема решений 1С тоже позволяет построить конвейер CI/CD.

В этой статье мы рассмотрим построение такого пайплайна на основе инструментов, предлагаемых 1С.

С подключением, хабровчане! Меня зовут Роман Волков, я Senior DevOps в МТС Web Services. Последние несколько лет мне приходилось создавать и адаптировать конвейеры на базе GItLab-CI, изменяя процесс автоматизации под каждую новую команду, стек, продукт и окружения эксплуатации. Чтобы облегчить жизнь себе и коллегам, я сделал небольшой внутренний фреймворк — FundaPipe, значительно упрощающий создание, развитие, переиспользование и применение самих конвейеров разработчиками.

В современном ИТ ландшафте множество методологий имеют в своем названии упоминание Ops: DevOps, ChatOps, MLOps и другие. По сути, все они так или иначе являются порождением философии DevOps и сегодня мы поговорим о GitOps — подходе к управлению инфраструктурой и развёртыванием приложений, который использует репозиторий Git в качестве центрального механизма.

GitOps позволяет командам декларативно определять конфигурацию инфраструктуры и приложений, а затем автоматически развёртывать их. Основная идея GitOps заключается в использовании Git как единого источника данных для декларативной инфраструктуры и приложений.

В этой статье мы рассмотрим, те преимущества, которые дает использование GitOps, а также развеем некоторые мифы вокруг GitOps..

Вышел релиз GitLab 18.2 с Duo Agent Platform в IDE (бета-версия) и настраиваемыми статусами рабочего процесса для тикетов и заданий

Ходит легенда, что однажды разработчики GitLab закупились шапками, сделанными из переработанных крышечек от бутылок. И их настолько вдохновила идея повторного использования, что они решили добавить такую возможность и в свой продукт. Подкрепив это всё стандартизацией CI, они представили комьюнити новый механизм — GitLab CI/CD components.

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

Вышел релиз GitLab 18.1 с бета-версией виртуальных реестров Maven и Duo Code Review в общем доступе.
Мы с радостью объявляем о релизе GitLab 18.1 с бета-версией виртуальных реестров Maven, фичей Duo Code Review в общем доступе, выявлением скомпрометированных паролей и компонентами CI/CD для достижения SLSA 1 уровня! Это лишь несколько из более 110 улучшений, добавленных в этом релизе. Читайте дальше, чтобы узнать обо всех основных изменениях.

Это история о том, как я устал держать в голове инфраструктуру по всем своим проектам.

Прод падает — а ты тратишь время на то чтобы вспомнить где лежит Grafana, где настраивается DNS, чей Docker Registry мы используем, есть ли у нас CDN и какой.

В итоге я запилил легковесное решение чтобы разобраться с вопросом системно, а не просто наклепать закладок в браузере.

Научись использовать Git как профессионал. Эта статья поможет тебе освоить самые популярные команды Git на реальных примерах. Узнай, как добавлять изменения, создавать коммиты, переключаться между ветками, объединять изменения и синхронизировать проект с удалённым репозиторием.

Итак вам надо клонировать репозиторий с компанейского репозитория и git просит какие-то непонятные пароли.
Знакома ситуация?

В этой заметке я написал как настроить ssh ключи.

В этой статье мы расскажем о том, как GitLab выявил и устранил «бутылочное горлышко» производительности в 15-летней функции Git, что повысило эффективность, обеспечив возможность применения более надёжных стратегий резервного копирования и снижения рисков.

Резервные копии репозиториев — важнейший компонент надёжной любой стратегии восстановления после сбоев. Однако с увеличением размеров репозиториев процесс создания надёжных бэкапов становится всё сложнее. Для резервного копирования нашего собственного репозитория Rails нам требовалось 48 часов. Это заставило нас искать невозможные компромиссы между частотой резервного копирования и производительностью системы. Мы хотели найти собственное внутреннее решение для наших клиентов и пользователей.

В конечном итоге, мы нашли источник проблемы в 15-летней функции Git со сложностью O(N²) и устранили его, внеся изменения в алгоритм, что экспоненциально уменьшило время резервного копирования. В результате мы обеспечили снижение затрат, уменьшение рисков и возможность создания стратегий резервного копирования, которые хорошо масштабируются месте с нашей кодовой базой.

Оказалось, что это проблема масштабируемости Git, влияла на всех его пользователей с крупными репозиториями. Ниже мы расскажем историю о том, как выявили и устранили проблему.

Мы с радостью объявляем о релизе GitLab 18.0 c GitLab Duo в планах Premium и Ultimate, автоматическими ревью мерж-реквестов с Duo Code Review, улучшенным контекстом Duo Code Review, фичей Repository X-Ray, доступной для Gitlab Duo с самостоятельным хостингом и многими другими фичами!

Мы с радостью объявляем о релизе GitLab 17.11 с настраиваемыми фреймворками соответствия требованиям, ещё большим числом ИИ-фич, доступных в GitLab Duo с самостоятельным хостингом, кастомными полями эпиков, тикетов и задач, входными параметрами конвейеров CI/CD , графическим интерфейсом для управления сервисными аккаунтами и многими другими фичами!

Привет! В первой статье цикла мы обсудили вводную про локализацию и её особенности. Пришло время поговорить про конкретные проблемы, с которыми можно столкнуться в процессе локализации. А ещё расскажу, как и кем выполнять тестирование.