Обновить
29.93

Git *

Система управления версиями файлов

Сначала показывать
Порог рейтинга
Уровень сложности

# Вышел релиз GitLab 12.10 с управлением требованиями и автоматическим масштабированием CI на AWS Fargate

Время на прочтение24 мин
Охват и читатели2.7K

Картинка для привлечения внимания


GitLab 12.10 помогает командам контролировать и улучшать соответствие требованиям с новой фичей «управление требованиями», уменьшать время цикла и ускорять поставку программного обеспечения благодаря CI с автоматическим масштабированием на AWS Fargate и более эффективно управлять портфелем проектов с отображением состояния тикетов и эпиков (в русской локализации GitLab «цели»).

Читать дальше →

Как использовать Prometheus для обнаружения аномалий в GitLab

Время на прочтение10 мин
Охват и читатели13K

Одной из базовых функций языка запросов Prometheus является агрегация временных рядов в режиме реального времени. Также язык запросов Prometheus можно использовать для обнаружения аномалий в данных временных рядов. 

Команда Mail.ru Cloud Solutions перевела статью инженера команды инфраструктуры GitLab, где вы найдете примеры кода, которые сможете попробовать на своих системах.
Читать дальше →

Руководство по Git. Часть №2: золотое правило и другие основы rebase

Время на прочтение6 мин
Охват и читатели32K
Посмотрим, что происходит, когда вы выполняете git rebase и почему нужно быть внимательным. 

Это вторая и третья части гайда по Git из блога Pierre de Wulf в переводе команды Mail.ru Cloud Solutions. Первую часть можно почитать тут.
Читать дальше →

Руководство по Git. Часть №1: все, что нужно знать про каталог .git

Время на прочтение4 мин
Охват и читатели63K



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

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

Это первая часть гайда по Git из блога Pierre de Wulf в переводе команды Mail.ru Cloud Solutions
Читать дальше →

Руководство по CI/CD в GitLab для (почти) абсолютного новичка

Время на прочтение13 мин
Охват и читатели490K

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


Наверное, у каждого разработчика, имеющего хотя бы один пет-проект, в определённый момент возникает зуд на тему красивых бейджиков со статусами, покрытием кода, версиями пакетов в nuget… И меня этот зуд привёл к написанию этой статьи. В процессе подготовки к её написанию я обзавёлся вот такой красотой в одном из своих проектов:


результаты


В статье будет рассмотрена базовая настройка непрерывной интеграции и поставки для проекта библиотеки классов на .Net Core в GitLab, с публикацией документации в GitLab Pages и отправкой собранных пакетов в приватный фид в Azure DevOps.


В качестве среды разработки использовалась VS Code c расширением GitLab Workflow (для валидации файла настроек прямо из среды разработки).

Читать дальше →

18 фич GitLab переходят в открытый исходный код

Время на прочтение6 мин
Охват и читатели6.9K

Картинка для привлечения внимания


Мы открываем исходный код фич со стадий Plan, Create, Verify, Package, Release, Configure и Defend.

Читать дальше →

IntelliJ IDEA 2020.1: Java 14, анализ потока данных в отладчике, новый режим LightEdit и многое другое

Время на прочтение4 мин
Охват и читатели8.9K

Привет, Хабр!


На прошлой неделе состоялся релиз IntelliJ IDEA 2020.1, и в этом посте мы коротко расскажем о самом интересном в новой версии. Из крупного: мы добавили поддержку Java 14, анализ потока данных в отладчике, режим редактирования файлов без открытия проекта (LightEdit) и новые фичи для разных фреймворков. Все подробности можно узнать на странице What’s new.


Читать дальше →

Unity + git = дружба: часть 1 джентльменский набор

Время на прочтение8 мин
Охват и читатели55K
image
Система контроля версий git уже давно стала стандартом де-факто в мире разработки, но для большинства разработчиков на Unity не секрет, что существует ряд трудностей связанных с особенностями Unity, которые мешают эффективно использовать ее совместно с git.

Вот список типичных проблем:

  1. в репозиторий попадают ненужные файлы или наоборот не попадают нужные
  2. множество больших файлов раздувает размер репозитория
  3. проблема с мерджем yaml файлов Unity
  4. в репозиторий добавлен только сам файл или только meta
  5. в проекте присутствуют пустые папки
  6. сложность автоматической нумерации версий и билдов
  7. неудобство использования кода между несколькими проектами

О решение этих проблем, связанных с совместным использованием git и Unity, вы можете прочитать в моем цикле статей.

В этой статье будет описано решение первых трех проблем
Читать дальше →

Проблемы доставки фич в больших проектах

Время на прочтение4 мин
Охват и читатели4.2K

Любому продукту, который в данный момент находится в сторе, грозят релизы. Наш проект не является исключением. Мы работаем по методологии scrum, разработка делится на спринты, обычно спринты не привязаны ко времени, а делятся на временные отрезки, зависящие от скоупа спринта. По итогам спринта обычно проводится релиз приложения в стор, который включает в себя новые фичи и некоторый багфикс.


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


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

В условиях постоянных релизов возникает вопрос: «Как же вести разработку?».
Ведь каждый разработчик должен делать задачи, делать ветки на эти задачи и куда-то по итогу их мерджить.


image

Читать дальше →

Content-based tagging в сборщике werf: зачем и как это работает?

Время на прочтение6 мин
Охват и читатели5K


werf — наша GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. В релизе v1.1 была представлена новая возможность в сборщике образов: тегирование образов по содержимому или content-based tagging. До сих пор типичная схема тегирования в werf предполагала тегирование Docker-образов по Git-тегу, Git-ветке или Git-коммиту. Но у всех этих схем есть недостатки, которые полностью решаются новой стратегией тегирования. Подробности о ней и чем она так хороша — под катом.
Читать дальше →

Как привести в порядок историю ваших коммитов в Git

Время на прочтение5 мин
Охват и читатели27K
Публикуем перевод статьи, которую мы нашли на hackernoon.com. Ее автор, Thiago Miranda, пишет о том, как сделать работу с Git более удобной и эффективной.

Читать дальше →

Собираем свой flow для git с нуля

Время на прочтение6 мин
Охват и читатели18K

На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).


Ее основными тезисами были:


  • GitFlow противоречит тезису "ветки должны быть короткоживущими".
    Это важно, потому что чем меньше живет ветка — тем меньше шанс конфликтов (не только git, но и логических)
  • GitFlow препятствует rebase-ам, чтобы сохранить merge-коммиты.
    Да, их можно сохранять и при ребейзах, но команды Git Flow не делают этого.
  • GitFlow отрицает подход Contunious Delivery, считая, что каждый акт Delivery должен совершаться релиз-инженером, да и в целом можно увидеть, что он ориентирован только на долгий релизный цикл.
  • GitFlow не дружит с микросервисами поверх мультирепозиториев (впрочем, тут вообще мало что подходит, это идея, которая всегда плохо заканчивается)
  • Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.


    Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.



Так что делать-то?

Читать дальше →

GitLab CI: 6 фич из последних релизов, которых мы так ждали

Время на прочтение8 мин
Охват и читатели103K


В эпоху повсеместного CI/CD мы сталкиваемся с большим спектром сопутствующих инструментов, в том числе и CI-систем. Однако именно GitLab стал для нас самым близким, по-настоящему «родным». Заметную популярность он снискал и в индустрии в целом*. Разработчики продукта не отставали от роста интереса к его использованию, регулярно радуя сообщество разработчиков и DevOps-инженеров новыми версиями.


Агрегация по месяцам и тегам репозитория GitLab

GitLab — тот случай, когда активное развитие приносит множество новых и интересных возможностей. Если для потенциальных пользователей это просто один из факторов выбора инструмента, то для действующих — ситуация такова: если вы не обновляли свою инсталляцию GitLab последний месяц, то с большой вероятностью пропустили что-то интересное. В том числе и регулярно выходящие security updates.

О наиболее значимых — т.е. востребованных нашими DevOps-инженерами и клиентами — нововведениях в последних релизах Community-редакции GitLab и пойдет речь в статье.
Читать дальше →

Ближайшие события

Миграция с Gitolite на GitLab с помощью Shell-скрипта

Время на прочтение9 мин
Охват и читатели2.1K

Процесс миграции нередко представляет собой трудную задачу, особенно, когда объем информации, который необходимо перенести, настолько велик, что выгоднее становится его автоматизировать. Именно необходимость миграции с Gitolite на GitLab и побудила меня написать статью о моем опыте в данном вопросе.

Читать дальше →

Вышел релиз GitLab 12.8 с обозревателем логов, NuGet и панелью управления соответствием требованиям

Время на прочтение29 мин
Охват и читатели4.1K

Картинка для привлечения внимания


Новый релиз GitLab 12.8 посвящен подходу «единое место»: для всех ваших логов, пакетов NuGet и контроля за соответствием требованиям. По аналогии с тем, что GitLab — это единое место для всего вашего жизненного цикла DevOps.

Читать дальше →

Пожалуйста, перестаньте рекомендовать Git Flow

Время на прочтение6 мин
Охват и читатели217K
Прим. перев.: Новая статья с критикой полюбившейся многим Git Flow получила столь заметное внимание, что даже оригинальный автор модели обновил публикацию 10-летней давности, актуализировав свой взгляд на её применение сегодня. Публикуем перевод как самой критики, так и официальной реакции.



Git-flow — это методология ветвления и слияния, сильно популяризированная заметкой 2010 года под названием «A Successful Git branching model» (была переведена на хабре как «Удачная модель ветвления для Git» — прим. перев.).

За последние десять лет бесчисленное множество команд пали жертвой этого громкого названия и оказались — не побоюсь этого слова — откровенно облапошены. В своей заметке автор утверждает, что они успешно внедрили эту модель в проекты, но умышленно не раскрывает подробности проектов, которые привели к этой «успешности».

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

На этом можно заканчивать, так? Ну, не совсем. Наверняка некоторые из вас скептически отнеслись к моей цепочке рассуждений, поэтому давайте копнем поглубже и попытаемся понять, почему модель ветвления Git-flow должна поджариться на медленном огне.
Читать дальше →

Laravel+Docker+Gitlab. С чего начать

Время на прочтение19 мин
Охват и читатели45K
Я обычно всегда обходился без докера и думал, что докер нужен только для больших проектов в больших компаниях. Но однажды я увидел как работает докер в паре с гитлабом у моего товарища и понял, что мне все таки стоит его изучить. Однако, как обычно это бывает, одной подходящей статьи я не нашел — они были либо слишком сложные, либо не полные, либо подразумевали, что вы все знаете само собой. Мне пришлось долго искать различные источники, соединять все это вместе и в итоге у меня получилось сделать простенький проект и CI/CD для него.

Всю работу можно разделить на три части: на локальной машине, на гитлабе и на сервере.

Итак, для реализации проекта нам понадобится аккаунт gitlab и удаленный сервер с виртуализацией KVM или XEN.

Часть 1. Локальная машина


На локальной машине необходимо установить docker.

Замечание
Тут небольшое отступление. Docker можно поставить как на Linux системах (как Ubuntu, например), так и на Windows и MacOS. По поводу macos я ничего сказать не могу, а вот установка под Windows не самая хорошая идея для начинающего. Как минимум из-за того, что все мануалы и документации написаны для linux систем. Так и из-за того, что можно нажить проблем с доступом к различным папкам и файлам. Также докер конфликтует с виртуальной машиной VirtualBox. Поэтому проще и быстрее будет сделать виртуальную машину с Ubuntu и работать под ней

Как Gitlab-CI наследует переменные окружения?

Время на прочтение3 мин
Охват и читатели40K

Переменные в Gitlab можно задать в нескольких местах:


  1. В настройках групп
  2. В настройках проекта
  3. Внутри .gitlab-ci.yml

При этом переменные в настройках групп и проекта можно задать как "файл"или "обычную переменную" и поставить галочки "защищено" и "маскировать".



Начнем с простого наследования и будем постепенно усложняться.


С конечным списком уровней приоритетов можно ознакомиться в конце документа.

Читать дальше →

Ревью кода системы средствами git

Время на прочтение3 мин
Охват и читатели23K

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


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


Как это сделать средствами самого git: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.


В общем суть метода уже изложена, ниже лишь немного подробностей.

Читать дальше →

Code review — улучшаем процесс

Время на прочтение7 мин
Охват и читатели18K
image

Представим команду, где не проводится Code review. Разработчики пишут код, и без проверок вносят все изменения в основную ветку. Спустя время расширяется функционал или находятся баги, они возвращаются к исходному коду, а там все переменные названы одной буквой, нет следования архитектуре, да и качество не самое лучшее. Этот некачественный код будет копиться и однажды наступит момент, когда, при любом мало-мальском нововведении, проект начнёт разваливаться: в лучшем случае – увеличится время разработки, в худшем – поддержка проекта станет невозможной. И это при том, что когда-то давно задача была выполнена и все хорошо работало.

Как этого можно избежать?
Читать дальше →

Вклад авторов