«Мы вовсе не собираемся разрушать ваш старый мир. Мы собираемся построить новый. Вот вы – жестоки: вы не представляете себе строительство нового без разрушения старого. А мы представляем себе это очень хорошо. Мы даже поможем вашему поколению создать этот ваш рай, выпивайте и закусывайте на здоровье. Строить, господин Банев, только строить. Ничего не разрушать, только строить.»
— А и Б Стругацкие, «Гадкие лебеди»

Этот пост я задумываю как рискованный эксперимент. Я хочу выяснить, могут ли ИТишники самоорганизоваться для создания открытого, свободного (от слова freedom, а не free beer), чистого, высококлассного «кода», используя привычные им инструменты (Git, fork, TDD, agile, stackoverflow, абстракции, юнит-тесты и прочее). Только этот «код» — это текст, который мог бы являться конституцией в альтернативной реальности (или фантастического рассказа), очень близкой к нашей. Если тебе не нравится чужой код — напиши свой.

Являются ли программисты теми, кто пишет сценарий будущего или просто теми, кто пишет патчи за деньги?

Заодно попробуем составить базу знаний лучших решений, какие были за историю конституций всех времен и народов, методов написаний и улучшений, а так же dark pattern'ы. Например, довольно поучительный кейс Исландии, как они писали-писали вики-конституцию, но так и не написали. Не помогли ни кастрюли, ни батя Бьорк, ни то, что их всего 300 000 человек.

(Надеюсь, что читатели Хабра смогут отнестись к моей идее конструктивно и не превратят в балаган. Если превратят — то скрою статью и завершу «эксперимент».)

Тема живая, продолжение в канале @GaaS

Одной из самых нужных функций, которой нет в бесплатной версии GitLab, является возможность голосования против обнуления репозитория контролировать Merge request (MR), используя обязательный code review.

Сделаем минимальный функционал сами — запретим Merge, пока несколько разработчиков не поставят «палец вверх» на MR.

Что изменилось со времени 12.0

Прежде чем приступить к описанию нового мажорного релиза 13.0, мы хотели бы уделить внимание пройденному пути. Мы столького достигли с момента выхода версии 12.0! Недавно в блоге вышел специальный пост, в котором мы сделали обзор релизов GitLab с 12.0 по 12.10. Три наших фаворита из этой серии релизов это управление требованиями, сетевая безопасность контейнеров и конвейеры (в русской локализации GitLab «сборочные линии») родитель-ребенок.

16 июня приглашаем вас на бесплатную онлайн-лекцию о быстрой автоматизации и развертывании ПО для хакатонов при помощи Ansible.

Лектор: старший разработчик платформы бизнес-сервисов «МегаФона» Антон Гладышев.

Зарегистрироваться

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

Зачастую мы сталкиваемся с тем, что вольный перевод на русский язык чаще оказывается невостребованным из-за того, что русские варианты узкоспециализированных терминов либо переведены слишком дословно, либо вариантом, который «в народе» не используется. Мы бы хотели, чтобы пользоваться локализованной версией GitLab было удобно, комфортно, а главное — понятно. Проблема также и в том, что так и внутри команды существуют разногласия в переводе тех или иных терминов, и естественно, мнение каждого из нас не отражает мнения большинства.

Доброго дня!

Меня зовут Соболев Андрей и сегодня я вам расскажу как мы приготовили .pre-commit hook на нашем проекте.

Вступление

Для начала пару слов, о том что такое в целом хуки (hooks) и для чего они могут быть нужны. Git «из коробки» предоставляет инструмент, который умеет запускать ваши скрипты при наступлении какого-либо события (к примеру пуш на сервер и т.п.)

.pre-commit это удобная надстройка над дефолтным git pre-commit hook, которая запускает скрипты описанные в .pre-commit-config.yaml перед созданием коммита. В теории звучит просто, перейдем к практике.

Tree of Dragons II by surrealistguitarist

Для тех, кто каждый день использует Git, но чувствует себя неуверенно, команда Mail.ru Cloud Solutions перевела статью фронтенд-разработчика Шейна Хадсона. Здесь вы найдете несколько трюков и советов, которые могут немного облегчить работу с Git, а также подборку статей и мануалов более продвинутого уровня.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.

  
  

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

  
  

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

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


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

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

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