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

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

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

На протяжении 4-х лет у нас выработался следующий формат команды разработки:

• 1 Project Manager, он же Product Manager, он же Delivery Manager.
• 4-5 программистов
• 1 Team lead
• 3-4 QA
• 1 Аналитик
• 1 Техпис (иногда он же и аналитик в одном лице).

В итоге команда размером около 10-11 человек. Таких команд (ячеек) у нас несколько.

Работа в основном в стиле стартапа, когда нет конкретной и подробной постановки. Очень часто эксперименты вроде “а давайте попробуем так, посмотрим что получится” или “вы классно все сделали, но теперь надо все совсем по-другому”.
За эти годы концепцию нашей работы можно описать одной фразой — это “стремительная смена концепции”.
Понятное дело, что применить в таких условиях различные методологии никак не удавалось.

Начинал в этой системе я как программист, потом Team lead, ну а теперь PM (DM). Т.е. руковожу, полностью участвую в проектировании и иногда даже пописываю. Во времена моего программирования у меня был замечательный ПМ (выходец из тестировщиков), которая поддерживала все мои идеи по автоматизации workflow. Даже более того, концептуально этот процесс придуман ей, а я уже смог его технически реализовать и в некоторых местах усовершенствовать.

Очередная (2012, 2011, 2010, 2009) перепись в сфере VCS.

Cколько времени я использую GitFlow и Semantic Versioning, меня все не покидает чувство, что чего-то в них не хватает. Обе концепции хороши, но так как они предлагают решения для проблем из разных областей, их совместное использование выглядит сложнее, чем должно быть.

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

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

Хорошие новости! Я написал тебе этот изумительный Интернет-пост. Я надеюсь, что смогу размазать достаточно Git-а по твоему лицу, чтобы понизить вероятность сделать что-то непоправимое, а так же уменьшить твой страх что-то сломать. Этого должно быть также достаточно, чтобы сделать документацию Git немного более понятной; она крайне тщательно и глубоко проработана и очень глупо, если ты все еще не прочитал половину.

Я постараюсь излагать коротко, но также, чтобы это было потенциально полезно тем людям, кто вообще никогда не сталкивался с контролем версий, поэтому повсюду будет разбросан 101 совет. Не бойся! Я не думаю, что пользователи Mercurial понятия не имеют, что такое патч.

Имеем следующую ситуацию:

В проекте присутствует файл super.config. В нем содержатся много разных настроек проекта. Например, конфигурация взаимодействия со сторонним сервисом и уровень логирования. Система контроля версий — git.

В чем проблема:

1. Этот файл должен находиться под версионным контролем, так как в нем содержатся «общие» настройки. Ну и сама структура файла ценна.
2. Каждый разработчик меняет уровень логирования под свои нужды и не хочет, чтобы эти изменения попадали в коммиты, и тем более в интеграционный репозиторий.
3. В этом файле периодически меняются общие настройки, и разработчик хочет их получать (pull) и публиковать (commit)

Гитхаб — великолепный агрегатор репозиториев и инструмент для коллективной работы. К сожалению, многие возможности конфигурирования на стороне сервера (вроде коммит хуков) остаются недоступными. Но ситуация постепенно меняется в лучшую сторону.

Случилось то, чего многие ждали довольно долго. А именно: недавно была анонсирована фича, под названием protected branches, которая позволяет настроить правила работы с ветками в рамках репозитория. Да, теперь можно запретить force push в master!

Под катом скриншоты и выдержки из блога разработчиков.

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

Вышла первая официальная версия Git for Windows. В отличие от msysGit инсталятор теперь содержит только Git (ранее же там было все необходимое для сборки Git), также теперь есть инсталятор для 64-битной версии.

Git — штука не то чтобы особо сложная, но гибкая. Иногда эта гибкость приводит к забавным последствиям. К примеру, посмотрите на этот коммит на GitHub. Он выглядит как нормальный коммит, но если вы клонируете себе данный репозиторий, то такого коммита в нем не найдете. Потому что это потерянный коммит, более известный как git loose object или же orphaned commit. Под катом — немного про внутренности Git, откуда такое берется и что делать, если оно вам встретилось.

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

Bitbucket анонсировал «Atlassian connect for Bitbucket»: возможность создавать плагины, встраиваемые в облачную часть Bitbucket, расширяющие его интерфейс и добавляющие новые возможности. Это качественный рывок в борьбе между Bitbucket, Github, Gitlab и TFS: если раньше мы были ограничены вебхуками и REST API, то теперь появилась возможность допиливать «под себя» и для других разработчиков непосредственно облачный интерфейс. Ужа доступно несколько расширений, основанных на nodejs SDK для создания плагинов и документация.

Без малого два года назад мы начали использовать в разработке нашего флагманского проекта СУБД ЛИНТЕР новую модель ветвления и управления подмодулями git-а. Десятки тысяч коммитов, сделанные за это время группой разработчиков, позволяют с определенной долей уверенности считать нововведения успешными. Эта статья — краткий обзор принципов организации хранилища исходных кодов в большом проекте на базе альтернативной реализации модулей git, сложившейся стратегии ветвления и инструментария linflow.

Доброго времени суток, уважаемые Хабровчане.

     В качестве краткой предыстории: год назад, придя на новое место работы в качестве руководителя отдела разработки БД (на базе Microsoft SQL Server), я испытал глубочайший шок от увиденного. Крупная компания, сложное веб-приложение, многомиллионные контракты, а разработка ведется на production-БД, баг-репорты поступают и обрабатываются по методике «кто громче крикнет» или «надо сделать прям вчера». Естественно ни о системе контроля версий, continuous integration, процедурах и workflow речи и не шло.

     Сегодня ситуация сильно изменилась (хотя, кого я обманываю — только начинает меняться) и я хотел бы поделиться как техническими, так и процедурными деталями решений, которые мы используем сейчас. Технические детали на 90% касаются непосредственно разработки для Microsoft SQL Server, а вот процедурные изменения у нас коснулись и веб-девелоперов, и инженеров, и аналитиков, и тестеров.

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

     Кому интересны подробности — добро пожаловать под кат.
Warning: очень много текста, описания процедур и процессов (которые, может, никому и не интересны).

На данный момент (начало апреля 2015) «официальная» версия Git для Windows — 1.9.5, в то время как для всех остальных платформ уже доступна версия 2.3.5. Отсюда и естественный интерес к обновлению Git for Windows до актуальной версии или замене его на альтернативный дистрибутив.

После небольшого исследования были обнаружены следующие способы (дистрибутивы) использования Git на платформе Windows.

Всем владельцам проектов на Google Code пришло соответствующее письмо.
Сокращенный перевод новости:

Начиная с сегодняшнего дня, мы прекращаем возможность создания новых проектов на Google Code. Сервис будет закрыт примерно через 10 месяцев к 25 января 2016 года. Ниже перечислены ссылки на инструменты миграции, спроектированные для того, чтобы помочь вам перенести ваши проекты.

Сроки:
12 Марта, 2015 — Создание новых проектов отключено.
24 Августа, 2015 — Переход в режим «только для чтения».
25 Января, 2016 — Закрытие сервиса. Будет доступно скачивание архива проекта включая исходный код, багтрекер и вики. Архив будет доступен до конца 2016 года.

Гугл будет продолжать предоставлять Git и Gerrit хостинг для таких проектов как Android и Chrome. Мы по-прежнему будем поддерживать зеркала таких проектов, как Eclipse, kernel.org и другие.

Здравствуйте!

Издательство «Питер» рассматривает возможность выпустить книгу по системе управления версиями Git.

Хотим посоветоваться с будущими читателями: какое издание вам будет наиболее интересно в русском переводе?
Мы сразу исключили книги ознакомительного уровня и выбрали три кандидатуры:

1. Новое издание (декабря 2014) книги Скотта Шакона



(Хотим сразу предупредить, что данная книга получится самой дорогой — розничная цена может достигать 1500 руб. Необходимо учесть это при принятии решения).

2. Классику от O'Reilly



3. Более краткое, но не сильно уступающее в информативности издание от Manning



Просьба голосовать:

Почему существует столько много различных пакетных менеджеров? Их можно встретить как во многих операционных системах (apt, yum, pacman, Homebrew), так и работая со многими языками программирования (Bundler, Cabal, Composer, CPAN, CRAN, CTAN, EasyInstall, Go Get, Maven, npm, NuGet, OPAM, PEAR, pip, RubyGems, и т.д. и т.п.). «Каждый язык программирования нуждается в собственном пакетном менеджере, это уже стало общепризнанной истиной». Что за необъяснимое притяжение заставляет языки программирования, один за другим, скатываться в этот обрыв? Почему бы нам просто не использовать уже существующие пакетные менеджеры?

Наткнулся сегодня на этот замечательный проект. Из файла README.md репозитория проекта:

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

Поехали!

Склонируйте репозиторий с помощью команды:

$ git clone https://github.com/hgarc014/git-game.git

Приветствую вас, коллеги! Сегодня утром гитхаб опубликовал подробную статью о свежевышедшой версии git. Забрать ее, как обычно, можно на официальном сайте, а под катом — краткий перевод что нового и интересного: push-to-deploy, ручное управление параметрами SSH, способ предотвратить зависание cron скриптов с клиентом git и многое другое.

Доброго времени суток!

Кто из вас вообще слышал, что такое StarTeam? Думаю мало кто, в прочем как и я пару месяцев назад.

Я до моего текущего места работы вообще не слышал о таком продукте компании Borland. Если спросить у гугла, то окажется, что данный продукт до сих пор существует и даже развивается, но как вы все догадались, речь пойдёт далеко не о последней версии и даже не о предпоследней. У меня версия 5.3, которая была разработана где-то в 2003 году, а установлена и запущена в оборот здесь в 2004 году. И вот почти 11 лет она работала и решала свои задачи.