Итак, 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 мы внесли функциональность, позволяющую улучшить качество кода, сократить время цикла разработки, а также упростить управление большими проектами.

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

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

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

Введение

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

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

Привет Хабр! Предлагаю вашему вниманию перевод статьи 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. Теперь можно составлять расписание выполнения конвейеров, что позволяет автоматизировать периодические задачи, такие как ночные сборки, профилактика или подтверждение внешних зависимостей.

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

В версии GitLab 9.1 появились канареечные развертывания. Они позволяют вам развертывать новый код на небольшой части вашей инфраструктуры. Если обнаружатся проблемы, они успеют затронуть лишь малую часть пользователей, и вы сможете легко откатиться к предыдущей версии. Это быстрая обратная связь от боевого окружения.

С новой фичей Service Desk ваши пользователи могут отправлять свои вопросы и сообщать о проблемах на специальный адрес электронной почты, отдельный для каждого проекта. По письму от пользователя Service Desk заводит конфиденциальную задачу (issue) в вашем проекте. Когда кто-либо комментирует задачу, пользователь получает этот комментарий в ответном письме. Это — встроенный непосредственно в GitLab канал обратной связи от пользователей.

Вышла новая версия платформы автоматизации операций доставки и развертывания изменений Clarive 6.8.

Платформа Clarive написана на Perl, имеет встроенный репозиторий Git, конфигурация и данные хранятся в MongoDB, устанавливается как правило на Linux, имеет визуальный редактор сценариев установки версий прикладного и системного ПО, поддерживает хосты и на windows, и на Unix, централизовано управляет средами разработки, тестирования, промышленной эксплуатации.

Что нового:

• Анализ причин сбоев сценариев
• Статический анализ код сценариев развертывания
• Стадии пайплайна
• Пошаговый просмотр исполнения задач
• Асоциация пайплайн правил с проектами
• Группы пользователей
• Анализ и просмотр логов в реальном времени
• Обработка событий
• Аутентификация MongoDB

Недавно мы выпустили GitLab 9.0, через 18 месяцев после выпуска версии 8.0. За это время мы сделали множество значительных изменений в GitLab, выпуская новую версию 22 числа каждого месяца. Давайте кратко подведем итоги, к которым мы пришли с выпуска 8.0, и посмотрим, как старые фичи соотносятся с новыми из 9 версии. Или вы можете перейти к фичам, появившимся в 9.0.

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

Итак, что дано:

• Есть большой репозиторий, содержащий множество папок. Каждая папка – это отдельный проект.

Что необходимо сделать:

• Одну из папок перенести в отдельный репозиторий с сохранением ее истории коммитов.

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

Я использовал стандартный гитовый filter-branch. За основу я взял следующие статьи:

• Moving Files from one Git Repository to Another, Preserving History
• Splitting a subfolder out into a new repository

В этом посте я хочу немного адаптировать процесс для лучшего восприятия.

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

Это не первоапрельская шутка

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

Github это незаменимый инструмент, прочно вошедший в жизнь практически каждого разработчика.

Хотя многие из нас используют его постоянно, не все знают, что существует большое количество сторонних (и бесплатных) сервисов и инструментов, которые тесно интегрированы с github и расширяют его функциональность.

В данной статье мы уделим внимание, в основном, инструментам, работающим в инфраструктуре npm. Полный список сервисов, интегрирующихся с github, можно посмотреть на странице github integrations directory.

Сегодня в выпуске:

• Настраиваем continuous integration c travis ci
• Настраиваем отчеты о test coverage с coveralls
• Мониторим статус зависимостей с david
• Настраиваем автоматическое обновление зависимостей с greenkeeper
• Улучшаем сообщения коммитов с commitizen
• Генерируем changelog и release notes с conventional-changelog
• Управляем задачами с zube

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

На прошлой неделе мы выпустили новую версию Upsource 2017.1 — первое крупное обновление в этом году. В новую версию вошло множество новых функций, ряд улучшений по части юзабилити и не только. Теперь к вашим услугам кросс-проектный текстовый поиск, браузерные уведомления, отслеживание прогресса ревью, поддержка squash/rebase, новые воркфлоу, базовая поддержку GitLab и многое другое!

Посмотрите краткий обзор новой версии на английском языке:

История с удалением базы конечно затмила все остальные новости про ГитЛаб. Так что если вы пропустили релизный пост про изменения и новые функции в GitLab 8.16, ниже — его перевод:

Наша цель — сделать участие в разработке доступным для каждого. Для этого мы делаем инструментарий GitLab простым в использовании, настройке и обслуживании. В предыдущей версии GitLab мы реализовали простую настройку непрерывной интеграции (continuous integration, CI) и автоматическое развертывание (deploy) в Kubernetes. А в первом релизе нового года мы делаем следующий шаг к нашей цели.

Чем хорош GitLab, так это тем, что будучи по габаритам слоном в посудной лавке, он умеет аккуратно устанавливаться и почти всегда работает с коробки. Но плохо умеет восстанавливаться и заботиться о себе, когда очень прямые руки вроде моих нарушают привычное ему окружение. Не буду углубляться в то, как мне удавалось убить его до состояния, когда даже удаление и установка с нуля не помогает, но во избежания очередной бесконечной эпопеи с дебагом и переустановкой сервера я вынес все это дело в Docker контейнер. Удобно — на рабочей машине нет миллиона зависимостей, примонтировал директории для репозиториев, логов и базы данных и все работает. Восстановление — пересоздать контейнер и скормить бэкап (кстати, не забудьте проверить свои бэкапы, как говорит опыт GitLab, это не лишнее).

С другой стороны, есть разрабатываемое Rails приложение, которое на реальной машине держит только код; Rails, gems, и все остальное покоится в Docker контейнере. Для своей работы оно использует Redis и Postgres, каждый находится в своем контейнере. Для каждого контейнера примонтирована директория, чтобы важные для приложения данные не оставались внутри.



Задача в том, чтобы Gitlab CI нормально отработал. Вроде все просто, но — он сам находится в контейнере.

Subversion vs. Git: Myths and Facts утверждает, что развеивает некоторые мифы о системах контроля версий. Я усомнился в их «фактах» и проверил некоторые из них. Результатом проверки стал подорванный авторитет сайта, и скептическое отношение к остальным утверждениям.

У Git есть строгие обязательства по обратной совместимости: многие продвинутые возможности скрыты за разнообразными опциями, а не применяются как поведение по умолчанию. К счастью, Git также поддерживает и алиасы, так что вы можете создавать свои собственные команды, которые делают всю характерную для Git магию. Под катом — подборка полезных (или как минимум забавных) алиасов, определённых в моём .gitconfig.

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

В GitLab 8.15 появилась фича Auto Deploy – автоматизированная настройка развертывания и приложений для ревью (Review Apps). Для проекта на Ruby on Rails такая настройка займёт меньше минуты. Посмотрите, как это работает, в видео на 1:42.

Вдобавок, доступ к вашим средам (environments) стал быстрее и проще: через терминал непосредственно в GitLab (там же на 5:18)

Мы хотим дать каждому возможность использовать всю мощь контейнеров (containers), непрерывной интеграции и развертывания (continuous integration and deployment, сокращенно CD/CI), приложений для ревью (review apps) и планировщиков контейнеров (container schedulers). В GitLab 8.15 мы взяли на себя всю сложную работу по настройке, и вся она происходит совершенно прозрачно. В демонстрационном видео мы настраиваем и разворачиваем Ruby-приложение с review apps, несколькими средами и чатопсом (chatops, управление инфраструктурой через интеграцию с чатом) на кластер Kubernetes примерно за 12 минут. Без GitLab такая задача обычно занимает дни, если не недели.

Для большинства из нас декабрь — месяц праздников и подарков. GitLab тоже получил в подарок много новых фич.

Введение

Сложно представить современную разработку без Continuous Integration. Многие компании выпускают по нескольку релизов в день и прогоняют тысячи тестов. Со времен Jenkins и Travis CI на рынке появилось много самых разнообразных инструментов. Большинство из них работают по модели SaaS — вы платите фиксированную плату за использование сервиса, или за количество пользователей.

Но использование hosted платформ не всегда возможно, например, если нельзя передавать код приложения, или не хочется зависеть от внешних сервисов. В таком случае выручают системы, которые можно установить на своих серверах (self-hosted). Бонусом вы имеете полный контроль над ресурсами и можете масштабировать их согласно вашим потребностям используя, к примеру, amazon ec2.

В этой статье представлен личный опыт использования нескольких opensource self-hosted continuous integration систем. Если вы использовали другие системы, расскажите об этом в комментариях.