Вышел GitLab 10.0 с Авто-DevOps, групповыми досками задач, новой навигацией и множеством других фич.

От формулировки идеи — до запуска и мониторинга на производстве. DevOps задаёт культуру и окружение, в которых разработка, тестирование и выпуск ПО происходят быстрее, чаще и надёжнее.

Всем привет! Хочу рассказать о консольной утилите, которая значительно увеличила мою продуктивность работы с Git, и, надеюсь, ускорит и вашу также. Называется она tig и была написана канадским программистом Джонасом Фонсека (Jonas Fonseca) ещё в далёком 2006-м году, но по настоящий день она активно развивается и поддерживается в великолепном состоянии. Я хочу показать её функционал (внимание, есть относительно тяжелые gif-ки внутри) и поделиться самыми удобными способами использования.

В продолжение статьи на тему что сказать git, чтобы он сделал то, что вам нужно и перед статьей как создать PR в чужой Open Source проект на GitHub думаю стоит полезным рассказать о том, что такое git rebase.

В GitLab 9.5 мы представляем верификацию коммитов GPG, шаблоны проектов, автоповтор неудавшихся работ CI, навигацию по дифф-файлу мерж реквестов, существенные улучшения производительности и многое другое.

До того, как я начал работать в одноклассниках я думал, что знаю как пользоваться системой контроля версий. Но там мне дали ссылку на документацию по git. Эту книгу можно читать бесконечно, но на мой взгляд для того, чтобы начать пользоваться git она абсолютно бесполезна. Это не проблема скажете вы и будете совершенно правы. На том же хабре есть куча статей на тему как пользоваться git. Но пару дней назад один мой товарищ попросил объяснить ему некоторые непонятые им моменты. Я объяснил, как смог и хочу поделиться просто еще одной шпаргалкой на тему «10 простых действий по использованию git в повседневной работе». Не такой уж и маленькой она получилась, поэтому я пока напишу только как работать с git для вашего рабочего проекта, а потом, отдельно, что делать если вы хотите вносить изменения в чужой проект.

Intro

Основам git мне пришлось научиться на своем первом месте работы (около трех лет назад).
С тех пор я считал, что для полноценной работы нужно запомнить всего-лишь несколько команд:

• git add <path>
• git commit
• git checkout <path/branch>
• git checkout -b <new branch>

И дополнительно:

• git push/pull
• git merge <branch>
• git rebase master (а что, можно еще и на другие ветки ребейзить? О_о)

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

Некоторое время назад на отличной конференции maintainerati я пообщался с несколькими друзьями-мейнтейнерами о масштабировании по-настоящему больших проектов open source и о том, как GitHub подталкивает проекты к определённому способу масштабирования. У ядра Linux абсолютно иная модель, которую мейнтейнеры-пользователи GitHub не понимают. Думаю, стоит объяснить, почему и как она работает и чем отличается.

Ещё одной причиной для написания этого текста стала дискуссия на HN по поводу моего выступления «Мейнтейнеры не масштабируются», где самый популярный комментарий сводился к вопросу «Почему эти динозавры не используют современные средства разработки?». Несколько известных разработчиков ядра энергично защищали списки рассылки и предложение патчей через механизм, похожий на пулл-реквесты GitHub, Но по крайней мере несколько разработчиков графической подсистемы хотели бы использовать более современный инструментарий, который гораздо легче автоматизировать скриптами. Проблема в том, что GitHub не поддерживает тот способ, которым ядро Linux масштабируется на огромное число контрибуторов, и поэтому мы просто не можем перейти на него, даже для нескольких подсистем. И дело не в хостинге данных на Git, эта часть явно в порядке, а дело в том, как на GitHub работают пулл-реквесты, обсуждение багов и форки.

Вышел GitLab 9.4: Связанные задачи и веб-мониторинг приложений

В GitLab 9.4 мы представляем связанные задачи, веб-мониторинг приложений, обновленную навигацию, групповые майлстоуны и многое другое!

Сложно кого-то удивить, когда работаешь открыто. Но такой подход позволяет нам рассказать о причинах наших нововведений, а также объяснить, как они позволят в будущем сделать GitLab еще лучше.

В GitLab 9.4 помимо добавления новой функциональности также закладываются основы многих будущих нововведений. Теперь вы официально можете связывать задачи друг с другом, серьезно расширена функциональность переменных в CI, а система мониторинга без дополнительных настроек анализирует гораздо больше метрик.

→ Вводная часть (со ссылками на все статьи)

Когда я выделил необходимое время для написания статьи об опыте использования системы контроля версий, я переговорил с несколькими людьми занимающимися разработкой (новичками и профессионалами) о системах контроля версий – плюсы и минусы использования, особенности их систем, сценарии использования. Разговор всегда начинался примерно одинаково: каждый считал, что может ответить на все мои вопросы и поделиться своим опытом, однако заканчивался разговор по-разному: кто-то прямо говорил, что в тонкостях не специалист, кто-то говорил, что это мне не понадобится – отсюда можно сделать вывод, что системы контроля версий не настолько простой инструмент совместной работы как многие о нём думают.

Эта статья продолжает первую часть, содержащую подробное описание нашего пайплайна:



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

Итак, я остановился на том, что созданный .gitlab-ci.yml не позволяет реализовать пайплайн в полной мере, поскольку GitLab CI не предоставляет директив для разделения задач по пользователям и для описания зависимостей выполнения задач от статуса выполнения других задач, а также не позволяет разрешить модификацию .gitlab-ci.yml только для отдельных пользователей.

Неделя GitLab CI на Хабре! В 2015 году мы уже писали о встроенной в GitLab системе Continuous Integration. GitLab часто ругают за предательство идеалов UNIX way и интеграцию слишком большого количества функций в одно приложение. Зато насколько удобно пользоваться этими функциями! За те полтора года, что прошли с момента нашей публикации, ребята сделали «Environments», добавили возможность сделать кнопку «раскатать на прод» и множество других улучшений. Под катом я расскажу о накопленном опыте, как небольшим командам автоматически собирать и выкладывать на прод/стейдж не только скрипты Voximplant для телефонии, но и другие проекты — сайты и сервисы.

Итак, GitLab CI: что можно ещё рассказать о нём? На хабре уже есть статьи про установку, про настройку раннеров, про командное использование, про GitLab Flow. Пожалуй, не хватает описаний того, как используется GitLab CI в реальном проекте, где задействовано несколько команд. А в современном мире разработки ПО это действительно так: ведь есть (как минимум) разработчики, тестировщики, DevOps- и релиз-инженеры. С подобным разделением на команды мы работаем уже несколько лет. В этой статье я расскажу о том, как мы, используя и улучшая возможности GitLab CI, реализовали и применяем в production для коллектива из нескольких команд процессы непрерывной интеграции (CI) и отчасти доставки приложений (CD).

Вышел GitLab 9.3: Code Quality и межпроектные графики конвейеров

В GitLab 9.3 мы представляем Code Quality, межпроектные графики конвейеров, индекс совместной разработки, улучшения локализации, описания сниппетов и многое другое!

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

Очень короткая заметка из серии «Хозяйке на заметку».

Предисловие

У плохо организованных разработчиков, типа меня, часто так бывает, что накомитишь всякого, а потом оказывается что не то и не туда, но git помнит всё и весь этот разгул анархии остаётся в истории.
Мне всегда казалось что это можно исправить, но сколько раз я не начинал искать ответа на этот вопрос — как в git удалить камиты — столько раз мне это не удавалось.
А всё потому что мои поиски приводили меня к rebase, а надо было искать reset.
На мой вкус вопрос недостаточно освещён и моя заметка призвана закрыть этот пробел.

Намного лучше дисциплинарные ограничения убирать инструментарным расширением
Автор статьи

Введение

При разработке информационной системы, то есть программы, нацеленной на хранение, работу с данными, обработку, анализ и визуализацию какой-то базы данных, одним из краеугольных камней стоит задача разработки БД. Когда я только начинал задаваться этим вопросом, казалось – что ни сделай, все равно будет криво.

На протяжении 5 лет разработки нескольких корпоративных ИС, я ставил и пытался решать вопросы, как тот или иной аспект разработки БД сделать удобным. Искал инструменты, помогающие что-то делать с БД, методологии. На удивление в этой области мало наработок. И в каждом подходе сразу видно – вот это нельзя, вот тут будет неудобно, тут слишком много дисциплинарных правил (см эпиграф)… В этой статье я попытался собрать те походы, которые считаю наиболее эффективными, и один, в добавление к собранным, представлю как венец моих исканий, который считаю наиболее «бронебойным».

Дано:

1. крупный проект на Java с фронтом на Angular,
2. разрабатываемый небольшой командой (~15 человек),
3. с использованием кучи (порядка 40 штук параллельно) фич-бранчей,
4. в git-репозитории;
5. несколько виртуальных серверов в приватном амазоновском облаке, которые можно использовать под задачи разработки;
6. разработчик, который немного подустал от Java, и хочет сделать что-нибудь по-настоящему полезное для постановки процессов.

Требуется:

1. обеспечить возможность команде QA инженеров тестировать каждый фич-бранч, как вручную, так и автоматизированно, на выделенном стенде, который не мешает остальным.

Консоль управления космическим кораблёмQA стендом

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

Это вторая часть моего руководства о том, как самостоятельно администрировать Redmine в долгосрочной перспективе. Первая часть была посвящена управлению собственной версией Redmine с помощью Git (ссылка на перевод).

Имея собственный репозиторий Redmine, пришло время ...

Привет Хабр! Предлагаю вашему вниманию перевод статьи Git Virtual File System Design History. Продолжение следует…

Виртуальная файловая система Git (Git Virtual File System, далее GVFS) была создана для решения двух основных задач:

• Скачивать только файлы необходимые пользователю
• Локальные команды Git должны брать в расчет не всю рабочую директорию (working directory), а только файлы, с которыми работает пользователь

В нашем случае основной сценарий использования GVFS — это репозиторий Windows с его 3 миллионами файлов в рабочей директории в сумме занимающих 270 Гбайт.

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

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

Также в версии 9.2 положено начало процесса локализации GitLab: аналитика цикла разработки (Cycle Analytics) теперь доступна на испанском и немецком языках. Локализация GitLab будет продолжена в последующих релизах, чтобы каждый мог вносить свой вклад независимо от родного языка.

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

Предлагаю читателям "Хабрахабра" перевод статьи "Хорошая практика в сообщении коммитов от OpenStack".

1 Git Commit Лучшая практика

Следующий документ основан на опыте разработки кода, устранении ошибок и просмотре кода в ряде проектов, использующих Git, включая libvirt, QEMU и OpenStack Nova. Рассмотрение других проектов с открытым исходным кодом, таких как Kernel, CoreUtils, GNULIB а также других, предполагает, что все они следуют достаточно распространенной практике. Это мотивировано желанием улучшить качество истории Git проекта Nova. Качество — это абстрактный термин для определения в разработке; когда для одного человека некий код «Красивый» (Thing of Beauty) — то для другого это «Костыль» (Evil Hack). Тем не менее мы можем сформулировать некоторые общие рекомендации о том, как и что делать, или, наоборот, чего не делать, когда отправляют Git коммиты для слияния с проектами в OpenStack.

Эта тема может быть разделена на две области:

1. Порядок объединения или разбиения на несколько коммитов
2. Информация в сообщениях коммитов