Git-Source Control на предприятии: предлагаемые инструменты и практики?
У меня проблема с этим методом на моем маршрутизаторе / модеме 3g, потому что если интернет отключен, маршрутизатор перенаправляет страницу на свою страницу ответа, так что вы все равно получаете пар, а ваш код считает, что есть интернет. Яблоки (или другие) имеют страницу с горячей точкой, которая всегда возвращает определенный ответ. Следующий образец возвращает ответ «Успех». Таким образом, вы точно убедитесь, что сможете подключиться к Интернету и получить реальный ответ!
public static bool CheckForInternetConnection()
{
try
{
using (var webClient = new WebClient())
using (var stream = webClient.OpenRead("http://captive.apple.com/hotspot-detect.html"))
{
if (stream != null)
{
//return true;
stream.ReadTimeout = 1000;
using (var reader = new StreamReader(stream, Encoding.UTF8, false))
{
string line;
while ((line = reader.ReadLine()) != null)
{
if (line == "<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>")
{
return true;
}
Console.WriteLine(line);
}
}
}
return false;
}
}
catch
{
}
return false;
}
8 ответов
Вопреки общепринятому мнению, я считаю, что использование DVCS - идеальный выбор в корпоративной среде, поскольку он обеспечивает очень гибкие рабочие процессы. Сначала я расскажу об использовании DVCS и CVCS, о лучших практиках, а затем, в частности, о git.
DVCS против CVCS в контексте предприятия:
Я не буду здесь говорить об общих плюсах и минусах, а сосредоточусь на вашем контексте. Распространено мнение, что использование DVCS требует более дисциплинированной команды, чем использование централизованной системы. Это связано с тем, что централизованная система предоставляет вам простой способ обеспечить ваш рабочий процесс, использование децентрализованной системы требует большего взаимодействия и дисциплины, чтобы придерживаться установленных соглашений. Хотя может показаться, что это приводит к накладным расходам, я вижу выгоду в усилении коммуникации, необходимой для того, чтобы сделать этот процесс хорошим.Ваша команда должна будет сообщить о коде, об изменениях и о статусе проекта в целом.
Еще одно измерение в контексте дисциплины - поощрение разветвлений и экспериментов. Вот цитата из недавней записи Блики Мартина Фаулера об инструментах управления версиями , он нашел очень краткое описание этого явления.
DVCS поощряет быстрое ветвление для экспериментов. Вы можете создавать ветки в Subversion, но тот факт, что они видны всем, отпугивает людей от открытия ветки для экспериментальной работы. Точно так же DVCS поощряет проверку работы: фиксацию неполных изменений, которые могут даже не скомпилировать или пройти тесты, в ваш локальный репозиторий. Опять же, вы можете сделать это в ветке разработчика в Subversion, но тот факт, что такие ветки находятся в общем пространстве, снижает вероятность того, что люди сделают это .
DVCS обеспечивает гибкие рабочие процессы, поскольку они обеспечивают отслеживание наборов изменений с помощью глобально уникальных идентификаторов в ориентированном ациклическом графе (DAG) вместо простых текстовых различий. Это позволяет им прозрачно отслеживать происхождение и историю набора изменений, что может быть весьма важным.
Рабочие процессы:
Ларри Остерман (разработчик Microsoft, работающий в группе Windows) написал отличную запись в блоге о рабочем процессе, который они используют в команде Windows.В частности, у них есть:
- Чистый, высококачественный ствол только для кода (главный репозиторий).
- Вся разработка происходит в функциональных ветках.
- Функциональные группы имеют командные репозитории
- Они регулярно объединяют последние изменения ствола в свои ветвь функций ( Прямая интеграция )
- Полные функции должны пройти несколько ворот качества, например обзор, тестовое покрытие, вопросы и ответы (репозитории сами по себе)
- Если функция завершена и имеет приемлемое качество, она объединяется в магистраль ( Обратная интеграция )
Как видите, наличие каждого из этих репозиториев существуют сами по себе, вы можете разделить разные команды, продвигающиеся с разной скоростью. Кроме того, возможность реализации гибкой системы контроля качества отличает DVCS от CVCS. Вы также можете решить свои проблемы с разрешениями на этом уровне. Только горстка людей должна иметь доступ к главному репо. Для каждого уровня иерархии создайте отдельный репозиторий с соответствующими политиками доступа. Действительно, такой подход может быть очень гибким на командном уровне. Вы должны предоставить каждой команде право решать, хотят ли они поделиться своим командным репозиторием между собой или они хотят более иерархического подхода, при котором только руководитель команды может принять участие в командном репо.
(Изображение украдено с сайта Джоэла Спольски hginit.com .)
На данный момент остается сказать одно: - хотя DVCS обеспечивает отличные возможности слияния, это никогда не заменять использование непрерывной интеграции. Даже в этот момент у вас есть большая гибкость: CI для основного репозитория, CI для командных репозиториев, репозиторий вопросов и ответов и т. Д.
Git в корпоративном контексте:
Git, возможно, не идеальное решение для корпоративного контекста, как вы уже отметили. Повторяя некоторые из ваших опасений, я думаю, что в первую очередь это:
Все еще несколько незрелая поддержка в Windows (пожалуйста, поправьте меня, если это недавно изменилось)Теперь в Windows есть клиент github для Windows , tortoisegit , SourceTree от atlassian- Отсутствие зрелых инструментов GUI,нет первоклассного гражданина интеграции vdiff / merge tool
- Несогласованный интерфейс с очень низким уровнем абстракций поверх его внутренней работы
- Очень крутая кривая обучения для пользователей svn
- Git очень мощный и делает его легко изменять историю, очень опасно, если вы не знаете, что делаете (а иногда будете, даже если думали, что знаете)
- Нет доступных вариантов коммерческой поддержки
Я не хочу начните здесь git vs. hg flamewar, вы уже сделали правильный шаг, переключившись на DVCS. Mercurial решает некоторые из вышеперечисленных вопросов, и поэтому я думаю, что он лучше подходит для корпоративного контекста:
- Поддерживаются все платформы, на которых запущен python.
- Отличные инструменты графического интерфейса на всех основных платформах (win / linux / OS X), во-первых интеграция инструмента class merge / vdiff
- Очень последовательный интерфейс, простой переход для пользователей svn
- Может делать большинство вещей, которые может делать git, но обеспечивает более чистую абстракцию. Опасные операции всегда явны. Расширенные функции предоставляются через расширения, которые должны быть включены явно.
- Коммерческая поддержка доступна от selenic.
Короче говоря, я думаю, что при использовании DVCS на предприятии важно выбрать инструмент с наименьшим трением. Чтобы переход был успешным, особенно важно учитывать различия в навыках разработчиков (в отношении VCS).
Уменьшение трения:
Хорошо, так как вы, кажется, действительно застряли в ситуации, осталось два варианта, ИМХО. Нет инструмента, чтобы сделать git менее сложным; git сложный.Либо вы столкнетесь с этим, либо обойдетесь с git: -
- Получите вводный курс git для всей команды. Это должно включать только основы и некоторые упражнения (важно!).
- Преобразуйте главное репо в svn и позвольте «молодым звездам» git-svn . Это дает большинству разработчиков простой в использовании интерфейс и может компенсировать недостаток дисциплины в вашей команде, в то время как молодые звезды могут продолжать использовать git для своих собственных репозиториев.
Если честно, я думаю, что у вас действительно проблема с людьми, а не с инструментами. Что можно сделать, чтобы улучшить эту ситуацию?
- Вы должны ясно дать понять, что, по вашему мнению, ваш текущий процесс будет иметь поддерживаемую базу кода.
- Потратьте время на непрерывную интеграцию. Как я уже отмечал выше, независимо от того, какой тип VCS вы используете, замены CI никогда не будет. Вы заявили, что есть люди, которые помещают дерьмо в главный репозиторий: пусть они исправят свое дерьмо, пока гаснет красный сигнал тревоги, и обвиняют их в том, что они нарушили сборку (или не соответствуют метрике качества или чему-то еще).
Для совместной разработки больше подходит gitosis или gitolite, но с открытым исходным кодом - Gitorious. Это приложение на Ruby on Rails, которое управляет репозиториями и объединяет их. Оно должно решить многие из ваших проблем.
Я инженер SCM в достаточно крупной организации разработки, и мы перешли на git с svn за последний год или около того. Мы используем его централизованно.
Мы используем gitosis для размещения репозиториев. Мы разбили наши монолитные репозитории svn на множество более мелких репозиториев git, поскольку модуль ветвления git в основном является репозиторием. (Есть способы обойти это, но они неудобны.) Если вам нужны виды управления доступом для каждой ветки, gitolite может быть лучшим подходом. Также существует версия GitHub внутри брандмауэра, если вы хотите потратить деньги. Для наших целей подойдет gitosis, потому что у нас есть довольно открытые разрешения для наших репозиториев. (У нас есть группы людей, которые имеют доступ на запись к группам репозиториев, и каждый имеет доступ на чтение ко всем репозиториям.) Мы используем gitweb для веб-интерфейса.
Что касается некоторых из ваших конкретных проблем:
- слияние: вы можете использовать инструмент визуального слияния по вашему выбору; в разных местах есть инструкции по его настройке. Тот факт, что вы можете выполнить слияние и полностью проверить его действительность в своем локальном репо, на мой взгляд, является большим плюсом для git; вы можете проверить слияние, прежде чем что-либо нажимать.
- Графические интерфейсы: у нас есть несколько человек, использующих TortoiseGit, но я особо не рекомендую его; кажется, что он странным образом взаимодействует с командной строкой. Я должен согласиться, что это область, которая нуждается в улучшении. (Тем не менее, я не поклонник графических интерфейсов для управления версиями в целом.)
- ветки отслеживания малых групп: если вы используете что-то, что предоставляет более детализированные ACL, например gitolite, сделать это достаточно просто, но вы также можете создать общую ветку, подключив локальные репозитории различных разработчиков - репозиторий git иметь несколько пультов.
Мы перешли на git, потому что у нас много удаленных разработчиков, и потому что у нас было много проблем с Subversion. Мы все еще экспериментируем с рабочими процессами, но на данный момент мы в основном используем его так же, как мы использовали Subversion. Еще одна вещь, которая нам понравилась, заключалась в том, что он открывал другие возможные рабочие процессы, такие как использование промежуточных репозиториев для проверки кода и обмена кодом между небольшими группами. Также многие люди начинают отслеживать свои личные скрипты и так далее, потому что создать репозиторий очень просто.
Да, я знаю, Линус никогда не предназначал это для этого.
На самом деле, Линус утверждает, что централизованные системы просто не могут работать.
И что не так с рабочим процессом диктаторов и лейтенантов?
Помните, git - это распределенная система; не пытайтесь использовать его как центральный.
(обновлено)
Большинство ваших проблем исчезнут, если вы не попытаетесь использовать git, как если бы это был «svn на стероидах» (потому что это не так).
Вместо того, чтобы использовать чистый репозиторий в качестве центрального сервера, на котором каждый может нажимать (и, возможно, облажаться), настройте несколько менеджеров интеграции, которые обрабатывают слияния, чтобы только они могли нажимать на чистый репозиторий.
Обычно эти люди должны быть руководителями группы: каждый лидер объединяет работу своей команды и помещает ее в благословенное хранилище.
Еще лучше, если кто-то другой (например, диктатор) берет от руководителей команд и интегрирует их изменения в благословенное хранилище.
В этом рабочем процессе нет ничего плохого, но мы перегружены работой стартап и нуждаемся в наших инструментах, чтобы заменить человеческое время и внимание; ни у кого нет пропускной способности даже для проверки кода, не говоря уже о том, чтобы быть доброжелательным диктатором.
Если у интеграторов нет времени проверять код, это нормально, но вам все равно нужны люди, которые интегрируют слияния от всех.
Выполнение git pulls не занимает много времени.
git pull A
git pull B
git pull C
git заменяет человеческое время и внимание; именно поэтому это было написано в первую очередь.
- Инструменты с графическим интерфейсом пользователя еще не развиты.
Инструменты с графическим интерфейсом довольно хорошо справляются с основными вещами.
Для сложных операций требуется мышление программиста / ботаника (например,Мне комфортно работать из командной строки). Чтобы понять концепции, нужно время, но это не так уж и сложно.
- Используя инструменты командной строки, очень легко испортить слияние и стереть чужие изменения
Это не будет проблемой, если у вас нет многих некомпетентных разработчиков с полным доступом на запись в «центральный репозиторий».
Но если вы настроите свой рабочий процесс так, что только несколько человек (интеграторов) будут писать в «благословенный» репозиторий, это не будет проблемой.
Git не позволяет легко испортить слияния.
Когда возникают конфликты слияния, git четко помечает конфликтующие строки, чтобы вы знали, какие изменения принадлежат вам, а какие нет.
Также легко стереть чужой код с помощью svn или любого другого (не распределенного) инструмента. На самом деле с этими другими инструментами намного проще, потому что вы склонны «сидеть на изменениях» долгое время, и в какой-то момент слияние может стать ужасно трудным.
И поскольку эти инструменты не знают, как объединять, вам всегда приходится объединять вещи вручную. Например, как только кто-то фиксирует файл, который вы редактируете локально, он будет отмечен как конфликт, который необходимо разрешить вручную; теперь , что - это кошмар обслуживания.
С git большую часть времени не будет конфликтов слияния, потому что git действительно может слиться. В случае возникновения конфликта git четко пометит строки для вас, чтобы вы знали точно , какие изменения принадлежат вам, а какие - от других людей.
Если кто-то стирает изменения других людей при разрешении конфликта слияния, это не будет ошибкой: либо потому, что это было необходимо для разрешения конфликта, либо потому, что они не знают, что делают.
Он не предлагает разрешений для репозитория для каждого пользователя, кроме глобальных прав только для чтения или чтения-записи.
Если у вас есть разрешение на ЛЮБУЮ часть репозитория, вы можете сделать то же самое для КАЖДОЙ части репозитория , поэтому вы не можете сделать что-то вроде создания ветки отслеживания для небольших групп на центральном сервере, с которой другие люди не смогут связываться.
- Трудно поощрять рабочие процессы, кроме «все идет» или «доброжелательного диктатора», не говоря уже о принуждении.
Эти проблемы исчезнут, когда вы перестанете пытаться использовать git, как если бы это была централизованная система.
- Неясно, лучше ли использовать один большой репозиторий (который позволяет всем возиться со всем) или множество репозиториев для каждого компонента (что создает головную боль при попытке синхронизировать версии).
Правосудие.
Какие у вас есть проекты?
Например: зависит ли версия xy проекта A именно от версии wz проекта B, так что каждый раз, когда вы проверяете xy проекта A, вы также должны проверять wz проекта B, иначе он выиграет » т строить? В таком случае я бы поместил и проект A, и проект B в один и тот же репозиторий, поскольку они, очевидно, являются двумя частями одного проекта.
Лучшая практика здесь - использовать свой мозг.
- С несколькими репозиториями также неясно, как реплицировать все источники, которые есть у кого-то еще, извлекая их из центрального репозитория, или сделать что-то вроде получения всего как из 4:30 вчера днем.
Я не понимаю, что вы имеете в виду.
Я тоже добавлю в сообщение "Вы думали".
Одно из преимуществ Bazaar - его гибкость. В этом он превосходит все остальные распределенные системы. Вы можете работать с Bazaar в централизованном режиме, в распределенном режиме или получить это: и то, и другое (это означает, что разработчики могут выбирать, какая модель им удобна или какая лучше всего подходит для их рабочей группы). Вы также можете отключить централизованный репозиторий, пока находитесь в дороге, и снова подключить его, когда вернетесь.
Вдобавок к этому отличная документация и кое-что, что порадует ваше предприятие: доступная коммерческая поддержка.
- Установите приличный веб-интерфейс, например Github FI
- Придерживайтесь относительно централизованная модель (изначально), чтобы люди чувствовали себя комфортно.
- Запустите сборку непрерывной интеграции для каждой общей ветки.
- Поделитесь хорошим набором глобальных параметров конфигурации git.
- Интегрируйте git в вашу оболочку с завершением bash и подсказкой с текущей веткой.
- Попробуйте IntelliJ Git Integration в качестве инструмента слияния.
- Убедитесь, что у вас соответствующий .gitignore.
Что касается пунктов 3 и 4 (разрешения на каждого пользователя, на раздел, на ветку), посмотрите на gitolite (рассматривается в книге Pro Git: http://progit.org/book/ch4-8.html).
Политика или нет, но Git является хорошим выбором DCVS, как никакой другой. Как и любой мощный инструмент, стоит потратить немного времени на понимание того, как этот инструмент должен работать, и для этого я настоятельно рекомендую книгу Pro Git. Пара часов, проведенных с ней, сэкономит много разочарований в долгосрочной перспективе.
Недавно мы перешли с svn на git. Поскольку git-daemon не работает с msysgit, мы выбрали подход центрального репозитория на сервере Linux с gitosis.
Чтобы исключить возможность облажаться с хозяином, мы просто удалили его. Вместо этого мы готовим все выпуски путем слияния веток, выбранных для тестирования, и помечаем слияние. Если он проходит тесты, фиксация помечается версией и запускается в производство.
Чтобы справиться с этим, у нас есть ротационная роль диспетчера релизов. Менеджер релизов отвечает за проверку каждой ветки перед тем, как она будет готова к тестированию. Затем, когда владелец продукта решает, что пора объединить утвержденные ветки вместе для нового тестового выпуска, менеджер выпуска выполняет слияние.
У нас также есть ротационная роль службы поддержки 2-го уровня, и, по крайней мере, для нас рабочая нагрузка такова, что можно выполнять обе роли одновременно.
Отсутствие мастера является преимуществом: невозможно добавить какой-либо код в проект, не пройдя через диспетчер релизов, поэтому мы непосредственно обнаружили, сколько кода было незаметно добавлено в проект раньше.
Процесс проверки начинается с того, что владелец ветки отправляет различие на доску для проверки и помещает на доске зеленую наклейку с названием ветки (у нас есть рабочий процесс на основе Канбана) в разделе «для проверки» или, если это часть завершенную пользовательскую историю, переместите всю карточку истории в «для просмотра» и поместите на ней пост. Менеджер релиза - это тот, кто перемещает карточки и помещает их в состояние «готово к тестированию», а затем владелец продукта может выбрать, какие из них включить в следующий тестовый выпуск.
При выполнении слияния менеджер выпуска также следит за тем, чтобы у коммита слияния было разумное сообщение о фиксации, которое можно использовать в журнале изменений для владельца продукта.
Когда выпуск запущен в производство, тег используется в качестве новой основы для веток, и все существующие ветки объединяются с ним. Таким образом, все ветки имеют общего родителя, что упрощает обработку слияний.