Базиран на Git контрол на източника в предприятието: Предложени инструменти и практики?

Противно на общоприетото мнение, смятам, че използването на DVCS е идеален избор в корпоративна среда, защото позволява много гъвкави работни процеси. Първо ще говоря за използването на DVCS срещу CVCS, най-добрите практики и след това по-специално за git.

DVCS срещу CVCS в корпоративния контекст:

Тук няма да говоря за общите плюсове/минуси, а по-скоро се фокусирам върху вашия контекст. Общата концепция е, че използването на DVCS изисква по-дисциплиниран екип от използването на централизирана система. Това е така, защото централизираната система ви предоставя лесен начин за налагане на вашия работен процес, използването на децентрализирана система изисква повече комуникация и дисциплина, за да се придържате към установените конвенции. Въпреки че това може да изглежда, че води до излишни разходи, виждам полза в увеличената комуникация, необходима, за да стане процесът добър. Вашият екип ще трябва да комуникира относно кода, промените и състоянието на проекта като цяло.

Друго измерение в контекста на дисциплината е насърчаването на разклоняването и експериментите. Ето цитат от скорошния запис на Мартин Фаулър в bliki в Инструментите за контрол на версиите, той намери много сбито описание на това явление.

DVCS насърчава бързото разклоняване за експериментиране. Можете да правите клонове в Subversion, но фактът, че те са видими за всички, обезсърчава хората да отворят клон за експериментална работа. По подобен начин DVCS насърчава проверката на работата: извършване на непълни промени, които може дори да не се компилират или да преминат тестове, във вашето локално хранилище. Отново можете да направите това в клон на разработчици в Subversion, но фактът, че такива клонове са в споделеното пространство, прави хората по-малко вероятно да го направят.

DVCS позволява гъвкави работни потоци, тъй като те осигуряват проследяване на набор от промени чрез глобални уникални идентификатори в насочена ациклична графика (DAG) вместо прости текстови разлики. Това им позволява прозрачно да проследяват произхода и историята на набор от промени, което може да бъде доста важно.

Работни процеси:

Лари Остерман (разработчик на Microsoft, работещ в екипа на Windows) има страхотна публикация в блог за работния процес, който използват в екипа на Windows. Най-вече те имат:

• Чист, висококачествен ствол само с код (главно репо)
• Цялото развитие се случва на разклонения на функции
• Екипите за функции имат екипни репозиции
• Те редовно обединяват най-новите промени в ствола в техния клон на функции (Напред интегриране)
• Пълните функции трябва да преминат през няколко прехода за качество, напр. преглед, тестово покритие, въпроси и отговори (репозиции сами по себе си)
• Ако функция е завършена и има приемливо качество, тя се обединява в ствола (Обратно интегриране)

Както можете да видите, като всяко от тези хранилища живее самостоятелно, можете да отделите различни екипи, които напредват с различни темпове. Освен това възможността за внедряване на гъвкава качествена гейт система отличава DVCS от CVCS. Можете също да разрешите проблемите си с разрешения на това ниво. Само шепа хора трябва да имат достъп до главното репо. За всяко ниво на йерархията имайте отделно репо със съответните политики за достъп. Наистина, този подход може да бъде много гъвкав на екипно ниво. Трябва да оставите на всеки екип да реши дали иска да споделя своето екипно репо помежду си или иска по-йерахичен подход, при който само ръководителят на екипа може да се ангажира с екипното репо.

(Снимката е открадната от hginit.com на Joel Spolsky.)

Едно нещо обаче остава да се каже на този етап: въпреки че DVCS предоставя големи възможности за сливане, това никога не е заместител на използването на непрекъсната интеграция. Дори в този момент разполагате с голяма гъвкавост: CI за багажното репо, CI за екипни репо, Q&A репо и т.н.

Git в корпоративния контекст:

Git може би не е идеалното решение за корпоративен контекст, както вече посочихте. Повтаряйки някои от вашите опасения, мисля, че най-вече те са:

• Все още малко незряла поддръжка на Windows (моля, поправете ме, ако това се е променило наскоро) Сега windows има github windows клиент, tortoisegit, SourceTree от atlassian
• Липса на зрели GUI инструменти, липса на първокласна гражданска интеграция на vdiff/сливане инструмент
• Непоследователен интерфейс с много ниско ниво на абстракции в допълнение към вътрешната му работа
• Много стръмна крива на обучение за потребителите на svn
• Git е много мощен и прави лесно модифицирането на хронологията, много опасно, ако не знаете какво правите (и понякога ще го направите, дори ако сте мислили, че знаете)
• Няма налични опции за търговска поддръжка

Не искам да започвам git срещу hg flamewar тук, вие вече направихте правилната стъпка, като преминахте към DVCS. Mercurial разглежда някои от точките по-горе и мисля, че следователно е по-подходящ в корпоративния контекст:

• Поддържат се всички платформи, които изпълняват python
• Страхотни GUI инструменти на всички основни платформи (win/linux/OS X), първокласна интеграция на инструменти за сливане/vdiff
• Много последователен интерфейс, лесен преход за потребителите на svn
• Може да прави повечето неща, които и git може да прави, но осигурява по-чиста абстракция. Опасните операции винаги са ясно изразени. Разширените функции се предоставят чрез разширения, които трябва изрично да бъдат активирани.
• Достъпна е търговска поддръжка от selenic.

Накратко, когато използвате DVCS в предприятие, мисля, че е важно да изберете инструмент, който създава най-малко триене. За да бъде успешен преходът, е особено важно да се вземат предвид различните умения между разработчиците (по отношение на VCS).

Намаляване на триенето:

Добре, тъй като изглежда наистина сте заседнали в ситуацията, остават две възможности IMHO. Няма инструмент, който да направи git по-малко сложен; git е сложен. Или се сблъсквате с това, или работите около git:-

1. Вземете въвеждащ курс по git за целия екип. Това трябва да включва само основите и някои упражнения (важно!).
2. Преобразувайте главното репо в svn и оставете "young-stars" git-svn. Това дава на повечето разработчици лесен за използване интерфейс и може да компенсира липсата на дисциплина във вашия екип, докато младите звезди могат да продължат да използват git за свои собствени репозитории.

Честно казано, мисля, че наистина имате проблем с хората, а не с инструментите. Какво може да се направи, за да се подобри тази ситуация?

• Трябва да изясните, че смятате, че текущият ви процес ще завърши с поддържаема кодова база.
• Инвестирайте известно време в непрекъсната интеграция. Както посочих по-горе, независимо кой вид VCS използвате, никога няма заместител на CI. Вие заявихте, че има хора, които пробутват глупости в главното репо: Накарайте ги да поправят глупостите си, докато червено предупреждение изгасва и ги обвинява за нарушаване на компилацията (или неспазване на показател за качество или каквото и да е).

Аз съм SCM инженер за сравнително голяма организация за разработка и ние преобразувахме към git от svn през последната година или нещо такова. Ние го използваме централизирано.

Използваме gitosis за хостване на хранилищата. Разбихме нашите монолитни svn хранилища на много по-малки git хранилища, тъй като разклонената единица на git е основно хранилището. (Има начини да се заобиколи това, но те са неудобни.) Ако искате контроли за достъп за всеки клон, gitolite може да е по-добър подход. Има и версия за вътрешната защитна стена на GitHub, ако искате да похарчите парите. За нашите цели gitosis е добре, защото имаме доста отворени разрешения за нашите хранилища. (Имаме групи от хора, които имат достъп за писане до групи от хранилища и всеки има достъп за четене до всички хранилища.) Използваме gitweb за уеб интерфейс.

Що се отнася до някои от вашите конкретни опасения:

• слива: можете да използвате инструмент за визуално сливане по ваш избор; има инструкции на различни места как да го настроите. Фактът, че можете да направите сливането и да проверите валидността му изцяло на вашето локално репо, според мен е основен плюс за git; можете да проверите сливането, преди да натиснете нещо.
• GUI: Има няколко души, които използват TortoiseGit, но аз наистина не го препоръчвам; изглежда взаимодейства по странни начини с командния ред. Трябва да се съглася, че това е област, която се нуждае от подобрение. (Въпреки това, аз не съм фен на GUI за контрол на версиите като цяло.)
• клонове за проследяване на малки групи: Ако използвате нещо, което предоставя по-фини ACL като gitolite, е достатъчно лесно да направите това, но можете също да създадете споделен клон, като свържете локалните хранилища на различни разработчици - git repo може да има множество дистанционни.

Преминахме към git, защото имаме много отдалечени разработчици и защото имахме много проблеми със Subversion. Все още експериментираме с работни потоци, но в момента го използваме основно по същия начин, както използвахме Subversion. Друго нещо, което ни хареса в него, беше, че отвори други възможни работни потоци, като използването на етапни хранилища за преглед на код и споделяне на код между малки групи. Също така се насърчи много хора да започнат да проследяват личните си скриптове и т.н., защото е толкова лесно да се създаде хранилище.

Да, знам, Линус никога не го е възнамерявал за това.

Всъщност Линус твърди, че централизираните системи просто не могат да работят.

И какво не е наред с dictator-and -работен процес на лейтенанти?

Запомнете, git е разпределена система; не се опитвайте да го използвате като централен.

(актуализиран)

Повечето от вашите проблеми ще изчезнат, ако не се опитате да използвате git, сякаш е svn на стероиди (защото не е).

Вместо да използвате голо хранилище като централен сървър, където всеки може да натиска (и потенциално да се прецака), настройте няколко мениджъра на интеграция, които обработват сливания, така че само те да могат да насочват към голото хранилище.

Обикновено тези хора трябва да бъдат ръководителите на екипа: всеки лидер интегрира работата на собствения си екип и я изпраща в благословеното хранилище.

Дори по-добре, някой друг (т.е. диктатор) изтегля от лидерите на екипи и интегрира техните промени в благословеното хранилище.

Няма нищо лошо в този работен процес, но ние сме преуморен стартъп и се нуждаем от нашите инструменти, които да заменят човешкото време и внимание; никой няма честотна лента дори да прави прегледи на кода, да не говорим за добронамерен диктатор.

Ако интеграторите нямат време да прегледат кода, това е добре, но все пак трябва да имате хора, които интегрират сливанията от всички.

Извършването на git pulls не отнема много време.

git pull A
git pull B
git pull C

git заменя човешкото време и внимание; затова е написано на първо място.

• GUI инструментите не са зрели

GUI инструментите могат да се справят доста добре с основните неща.

Разширените операции изискват мислене на кодер/изперка (напр. удобно ми е да работя от командния ред). Отнема малко време, за да разберете концепциите, но не е толкова трудно.

• С помощта на инструментите на командния ред е твърде лесно да прецакате сливането и да заличите промените на някой друг

Това няма да е проблем, освен ако нямате много некомпетентни разработчици с пълен достъп за запис до централното хранилище.

Но ако настроите работния си процес така, че само няколко души (интегратори) да пишат в благословеното хранилище, това няма да е проблем.

Git не улеснява прецакването на сливания.

Когато има конфликти при сливане, git ясно ще маркира конфликтните редове, така че да знаете кои промени са ваши и кои не.

Също така е лесно да заличите кода на други хора със svn или друг (не-dsitributed) инструмент. Всъщност е много по-лесно с тези други инструменти, защото сте склонни да седите върху промените дълго време и в даден момент сливането може да стане ужасно трудно.

И тъй като тези инструменти не знаят как да обединяват, в крайна сметка винаги трябва да обединявате нещата ръчно. Например, веднага щом някой направи ангажимент към файл, който редактирате локално, той ще бъде маркиран като конфликт, който трябва да бъде разрешен ръчно; сега това е кошмар за поддръжка.

С git през повечето време няма да има конфликти при сливане, защото git всъщност може да слива. В случай, че възникне конфликт, git ясно ще маркира редовете вместо вас, така че да знаете точно кои промени са ваши и кои от други хора.

Ако някой заличи промените на други хора, докато разрешава конфликт на сливане, това няма да е погрешка: или ще бъде, защото е било необходимо за разрешаването на конфликта, или защото не знае какво прави.

• Той не предлага разрешения за хранилище за всеки потребител освен глобалните привилегии само за четене или четене и запис

• Ако имате разрешение за ВСЯКА част от хранилище, можете да направите същото нещо за ВСЯКА част от хранилището, така че не можете да направите нещо като създаване на клон за проследяване на малка група на централния сървър, който другите хора не могат забърквам се с.

• Трудно е да се насърчат, да не говорим за налагане на работни потоци, различни от „всичко върви“ или „доброжелателен диктатор“.

Тези проблеми ще изчезнат, когато спрете да се опитвате да използвате git, сякаш е централизирана система.

• Не е ясно дали е по-добре да се използва едно голямо хранилище (което позволява на всеки да се забърква с всичко) или много хранилища за всеки компонент (което създава главоболия при опитите за синхронизиране на версии).

Присъда.

Какви проекти имате?

Например: зависи ли версия x.y на проект A точно от версия w.z на проект B, така че всеки път, когато проверявате x.y на проект A, вие също трябва да проверите w.z на проект B, в противен случай няма да се изгради ? Ако е така, бих поставил и проект A, и проект B в едно и също хранилище, тъй като те очевидно са две части от един проект.

Най-добрата практика тук е да използвате мозъка си

• С множество хранилища също не е ясно как да копирате всички източници, които някой друг има, като изтеглите от централното хранилище, или да направите нещо като получаване на всичко от 4:30 вчера следобед.

Не съм сигурен какво имаш предвид.

Силно препоръчвам http://code.google.com/p/gerrit/ за корпоративна работа. Той ви дава контрол на достъпа плюс вграден работен процес, базиран на преглед. Удостоверява се срещу всяка LDAP система. Можете да го свържете към Hudson с http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin, който ви позволява да създавате и тествате промени, докато те все още са в процес на преглед; това е наистина впечатляваща настройка.

Ако решите да използвате gerrit, препоръчвам да се опитате да запазите доста линейна история, а не разклонена история, както харесват някои хора с отворен код. Герит формулира това като „разрешаване на промени само за бързо превъртане напред“. След това можете да използвате разклоняване и сливане в повече по начина, по който сте свикнали, за издания и какво ли още не.

Отговарям на този въпрос въз основа на моя опит като мениджър разработчици в голяма телекомуникационна компания, където приехме Git през 2010 г.

Тук имате доста различен набор от проблеми:

• работни потоци
• клиентски инструменти
• контрол на достъпа до сървъра и интеграция

Работни процеси

Успешно възприехме режим на централно хранилище: това, което имаме в нашия корпоративен проект (голям портал за 5 милиона потребителска база) е де факто централно хранилище, което произвежда официалните компилации, след което се преминава през процеса на доставка (който в нашия случай, се състои от три нива на тестване и две внедрявания). Всеки разработчик управлява собственото си репо, а ние работим на база клон за функция.

Клиентски инструменти

Вече има няколко налични опции, сега това е много пренаселено място. Много разработчици успешно използват IntelliJ Idea и Eclipse с приставката Git, без никакви други неща. Също така повечето от разработчиците на Linux използват CLI git клиент, без никакъв проблем. Някои разработчици на Mac успешно използват Tower Git. Моля, обърнете внимание, че нито един от тези клиенти не може да попречи на потребителя да "обърка" централното хранилище: необходим е механизъм за контрол от страна на сървъра

Контрол на достъпа до сървъра и интеграция

Ако искате да избегнете разработчиците да „объркат“ вашето Git хранилище, наистина трябва да изберете решение, което:

• излага приличен уеб администраторски интерфейс за извършване на всяка операция
• ви позволява да налагате потребителски самоличности (използването на „голо“ Git хранилище е изключително лесно за ангажиране от името на някой друг)
• ви осигурява фина сигурност (така че например можете да предотвратите FORCE-PUSH и да зададете някои клонове да четат само за някои разработчици / групи)
• интегриране с вашата корпоративна система за удостоверяване (т.е. LDAP, Windows ActiveDirectory)
• ви предоставя пълен одит (съответствието със SOX понякога е много важно за големите корпорации)

Няма толкова много готови за използване решения от страна на сървъра, които могат да помогнат за това, предлагам ви да разгледате едно от тези:

• Gitorious: може да осигури базово ниво на защита на достъпа, но му липсва фин контрол на разрешенията веднага, така че вероятно ще трябва да направя малко кодиране, за да се справя със сценарии като разрешения на ниво клон. Освен това липсва интеграция със съществуващите корпоративни механизми за удостоверяване
• GitHub Enterprise: публикуван наскоро от GitHub, включва GitHub във вашата компания. Липсва му SOX съответствие и фина сигурност
• Gerrit: може да осигури фина сигурност на ниво на достъп и интеграция с корпоративни системи за удостоверяване, но му липсва SOX съответствие и SSO. Също така някои операции могат да се извършват само чрез SSH чрез CLI
• GitEnterprise: предоставя разрешения на ниво клон, SSO, SOX съответствие, пълно уеб базирано администриране. Наскоро беше интегриран и с Gerrit, така че ви предоставя и пълен екземпляр на Gerrit

Надявам се това да помогне!

Изглежда, че проблемът ви е, че не сте решили или не сте въвели работен процес. Git е достатъчно гъвкав, за да го използвате като svn или всяка друга VCS, но е толкова мощен, че ако не установите правила, които всички трябва да следват, тогава просто ще се окажете в бъркотия. Бих препоръчал работния процес диктатор-лейтенант, който някой спомена по-горе, но комбиниран с разклонения модел, описан от Винсънт Драйсен. За повече информация вижте тези скрийнкастове от Дейвид Бок и този от Марк Дерикът.

В инструментите потребителите на MacOS-X намират GitX (http://gitx.frim.nl/) за много прост и ефективен. Недостатъкът е, че не поддържа Git Client hooks (тези под $GIT_ROOT/.git/hooks).

Като цяло твърдо искам да избера инструмент, който поддържа прецизен контрол на достъпа на: - клонове (за да се отделят клоновете със стабилно издание със стриктна сигурност от клоновете на теми, които се нуждаят от повече подвижност и гъвкавост) - прилагане на самоличност (автор / извършител). Това е КЛЮЧ за SOX - git команди ограничения - одит-следа. Това е КЛЮЧ за SOX

Тези, които съм използвал успешно с тези функции, са:

1. Преглед на Gerrit Code (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit), използва Gerrit 2.1.8 зад кулисите

P.S. Не подценявайте съответствието със SOX и CMMI: много пъти има ограничен избор, който имате, който е продиктуван от корпоративните политики на вашата компания за сигурност.

Надявам се това да помогне.

Лука.

Наскоро преминахме от svn към git. Тъй като git-daemon не работи с msysgit, ние избрахме подход на централно хранилище на Linux сървър с gitosis.

За да елиминираме възможността да прецакаме майстора, ние просто го изтрихме. Вместо това ние подготвяме всички издания, като сливаме клоновете, които са избрани за тестване, и маркираме сливането. Ако премине тестовете, ангажиментът се маркира с версия и се пуска в производство.

За да се справим с това, имаме ротационна роля на мениджър на версиите. Мениджърът на версиите е отговорен за прегледа на всеки клон, преди да е готов за тестване. След това, когато собственикът на продукта реши, че е време да обедини одобрените клонове заедно за нова тестова версия, мениджърът на версиите извършва сливането.

Имаме и ротационна роля на помощно бюро от 2-ро ниво и поне за нас натоварването е такова, че е възможно да имаме и двете роли едновременно.

Като предимство от това, че нямате главен, не е възможно да добавите никакъв код към проекта, без да преминете през мениджъра на версиите, така че открихме директно колко код е бил тихо добавен към проекта преди.

Процесът на преглед започва със собственика на клона, който изпраща разликата до таблото за преглед и поставя зелен лист върху бялата дъска с името на клона (имаме работен процес, базиран на Kanban) под „за преглед“ или ако е част от завършен потребител история, преместете цялата карта с история на „за преглед“ и поставете публикацията върху нея. Мениджърът на повторната версия е този, който премества картите и ги поставя в „готови за тест“ и след това собственикът на продукта може да избере кои да бъдат включени в следващото тестово издание.

Когато прави сливането, мениджърът на версиите също се уверява, че ангажиментът за сливане има разумно съобщение за ангажимент, което може да се използва в регистъра на промените за собственика на продукта.

Когато версия е пусната в производство, етикетът се използва като нова база за клонове и всички съществуващи клонове се обединяват с него. По този начин всички клонове имат общ родител, което улеснява обработката на сливания.

Ще добавя и публикация „Обмисляли ли сте“.

Едно от страхотните неща на Bazaar е неговата гъвкавост. Това е мястото, където побеждава всички други разпределени системи. Можете да управлявате Bazaar в централизиран режим, разпределен режим или да получите това: и двете (което означава, че разработчиците могат да избират кой модел им харесва или кой работи най-добре за тяхната работна група). Можете също така да изключите централизирано хранилище, докато сте на път, и да го свържете отново, когато се върнете.

На всичкото отгоре отлична документация и нещо, което ще направи вашето предприятие щастливо: налична търговска поддръжка.

• Инсталирайте приличен уеб интерфейс, като Github FI
• Придържайте се към сравнително централизиран модел (първоначално), за да се чувствате комфортно на хората.
• Изпълнете изграждане на непрекъсната интеграция за всеки споделен клон.
• Споделете добър набор от глобални опции за конфигурация на git.
• Интегрирайте git във вашата обвивка с bash завършване и подкана с текущия клон.
• Опитайте Git Integration на IntelliJ като инструмент за сливане.
• Уверете се, че .gitignore е подходящо.

Относно точки 3 и 4 (разрешения за потребител, за секция, за клон), погледнете gitolite (разгледано в книгата Pro Git: http://progit.org/book/ch4-8.html).

Политика или не, Git е толкова добър избор на DCVS, колкото всеки друг. Като всеки мощен инструмент, струва си да отделите малко време предварително, за да разберете как е проектиран да работи инструментът и за тази цел горещо препоръчвам книгата Pro Git. Няколко часа, прекарани с него, ще спестят много разочарования в дългосрочен план.

GUI: В момента TortoiseGit v1.7.6 трябва да е добре за повечето ежедневни операции. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule и др... Поддържа и x64 естествено

За да използвате git ефективно в екип за разработка с много разработчици, е необходима CI система, която изгражда и тества непрекъснато. Дженкинс предоставя такова превозно средство и аз силно го препоръчвам. Частта за интегриране трябва да се направи независимо от всичко и е много по-евтино да се прави това по-рано и по-често.

По-подходящ за съвместна разработка от gitosis или gitolite, но с отворен код е Gitorious. Това е приложение Ruby on Rails, което управлява управлението на хранилищата и сливането. Това трябва да реши много от вашите проблеми.

Git позволява създаване на частни клонове. Това насърчава разработчиците да се ангажират често, за да разбият модификациите на малки ангажименти. Когато разработчикът е готов да публикува промените си, той насочва към централния сървър. Той може да използва предварително ангажирани скриптове, за да провери своя код, ако е необходимо.

NXP управлява Git и Subversion с една обща платформа (в корпоративен мащаб), интегрирайки мобилна разработка за Android с традиционни софтуерни проекти: http://www.youtube.com/watch?v=QX5wn0igv7Q