Почему крупные финансовые / страховые компании должны использовать git и / или github?

Я работаю на крупном предприятии (30 тыс. Сотрудников) в финансовой / страховой отрасли. Хотя «ИТ» не является нашей основной задачей, давайте будем честными, это отрасли, основанные на информации, и компании с лучшими технологическими преимуществами, похоже, быстрее продвигаются вперед.

В моей компании много команд разработчиков программного обеспечения. Они повсюду на карте с контролем версий, не говоря уже о используемых языках / платформах. Некоторые не используют (я знаю), некоторые используют PVCS, некоторые используют VSS, а наиболее просвещенные используют SVN.

Я хочу привнести мерзавца на свое предприятие. Точнее, я хочу привести GitHub (частные репозитории). Я знаю нужных людей, с которыми можно поговорить об этом, но давайте снова будем честными, такие резкие шаги обычно сбиваются в условиях большого предприятия из-за неопределенных проблем безопасности или того факта, что никто из наших конкурентов не использует их (и я могу в качестве ссылок приводите только jQuery, Ruby on Rails, Facebook и т. д.).

Итак, мой вопрос заключается в следующем. Каковы наиболее веские причины того, почему крупному предприятию следует медленно и преднамеренно переходить с PVCS / VSS / SVN на хост-решение git, такое как GitHub (private repo). Конечно, часть моего плана включает POC для второстепенного проекта развития.

Есть несколько вещей, которые могут меня беспокоить, как незаинтересованная третья сторона. Итак, позвольте мне задать вам несколько вопросов, на которые вы лучше ответите (в свой ИТ-отдел):

• Любой контроль версий лучше, чем никакой. У нас есть из чего выбирать, что с ними не так?
• Распределенный контроль версий? Что это? Как мы это контролируем ?
• Сколько это стоит? Не только программное обеспечение, но и серверы, лицензии, обслуживание и т. Д.
• Я не доверяю GitHub или любому стороннему хостингу. Нам нужно сделать все на месте. Почему мы не можем настроить наш собственный сервер?
• Можем ли мы запустить его на Windows? Знаете, мы должны сохранить его на нашем текущем уровне.
• Как мы обеспечиваем вещь? SVN у нас получается, но меня это пугает.

Это самые первые вопросы, которые возникнут. Что касается VSS и PVCS, вы, вероятно, можете привести несколько разумных аргументов (например, искажающую историю версий VSS). SVN будет немного сложнее. Я настоятельно рекомендую сосредоточиться на возможностях слияния GIT, а также рекомендую непредвзято относиться к Mercurial. Каждый аргумент для GIT также является аргументом для Mercurial - и Mercurial имеет более зрелую поддержку Windows.

Безопасность имеет первостепенное значение для финансовых и государственных учреждений. Они будут чрезвычайно устойчивы к внешним ресурсам. С точки зрения управления рисками подумайте, что может произойти, если кто-то взломал GitHub и украл исходный код или обнаружил уязвимость безопасности, задокументированную в системе отслеживания проблем. Это было бы разрушительным для компании. С точки зрения чистого управления, если компания легальнодолжен платить вам за каждый час вашей работы, как они могут отслеживать, работаете ли вы дома, когда ресурсы находятся за пределами их сети VPN? С другой стороны, как они могут помешать вам осуществить корпоративный шпионаж, когда все ресурсы доступны за пределами компании? Это аргументы ИТ и менеджмента против аутсорсинга хостинга. Крупная компания имеет смотреть на вещи таким образом. Для небольшой компании вы смотрите на итоговую сумму и то, сколько будет стоить внедрение всех этих услуг.

На самом деле крупной компании дешевле делать это дома. У них уже есть ИТ-ресурсы, им просто нужно немного переложить обязанности. И если решение в значительной степени заботится о себе, требуя лишь периодического обслуживания (резервное копирование и управление пользователями), это еще одна причина, чтобы держать его внутри корпоративных дверей.

Что касается хостинга Windows, это вопрос организации по организации. Несколько компаний проглотили Windows Koolaid. Другие проглотили koolaid Linux. Другие рассматривают это на индивидуальной основе. Вы должны будете играть по правилам, которые ИТ-отдел установил для вашей организации. Пока ваше решение может быть размещено на любом из них, вы золотой.

Наконец, в такой крупной организации гарантировано, что все феодалы захотят делать все по-своему. У всех них есть убедительные аргументы, почему они выбрали VSS, PVCS, SVN или что у вас есть. Для него они все одинаковы. Единственный способ консолидироваться в такой большой организации - это сделать приказ сверху указом. Такие заказы всегда встречают сопротивление, и это, вероятно, не то, что ваша компания хочет делать, если нет очевидных преимуществ совокупной стоимости владения (TCO) при наличии стандартизированной системы контроля версий.

Я также работаю на финансовом / страховом предприятии (хотя и не таком большом, как то, на которое вы сейчас работаете). У нас также есть несколько групп разработчиков, и хотя предприятие выбрало специально продукты Microsoft для разработки, все еще не существует основной архитектуры, языка или системы контроля версий. Мы все используем .Net, но у нас есть несколько проектов в разных версиях фреймворка и на разных языках. Некоторые проекты используют VSS, другие TFS. Теперь у нас есть новый архитектор более высокого уровня в качестве менеджера по обеспечению качества, и он возглавил более масштабный переход от нашего отслеживания ошибок, контроля исходного кода, использования инфраструктуры к более универсальной реализации TFS для всего этого. Это стало возможным только благодаря тому, что он а) чрезвычайно опытен в природе программного обеспечения,

Обращаясь к этому в своей собственной организации, вы должны сначала рассмотреть некоторые вещи:

1. Почему вы так очарованы GitHub в качестве ответа? Вы ищете общий источник контроля или вы ищете причину для реализации того, что вам удобно? Я не знаю ответа (и, честно говоря, все равно), но этот вопрос возникнет, когда вы начнете ссориться в делах других людей.
2. Вы в настоящее время связаны с одной из этих программных команд? Если да, вам может понадобиться найти независимого, хорошо позиционированного человека, чтобы отстаивать эту концепцию. В противном случае другие команды разработчиков могут просто почувствовать, что вы пытаетесь запечатлеть на них свое мышление. Это сделает их еще более устойчивыми к концепции, поскольку у них уже есть что-то, что работает (по их мнению).
3. Делали ли вы какие-либо контакты с людьми из других команд, чтобы получить поддержку этой концепции? У других разработчиков есть подобные мнения или проблемы? Еще один способ добиться этого - создать критическую массу последователей среди людей, выполняющих работу. По мере того, как все больше людей будут требовать хранилища общих источников, руководство должно будет это заметить.
4. Достаточно ли вы знакомы с кодом / процессами / требованиями других команд, чтобы сказать, что GitHub будет (или не будет) работать на них?

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

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

Такие компании захотят централизовать свои репозитории. SVN, VSS и PVCS имеют одну общую черту - все они являются клиент-серверной архитектурой. Git разработан как распределенный VCS, и по своей природе децентрализован.

GitHub - еще более проблематично. Это внешний сервис. Исходный код во внешней службе - это то, что руководство, скорее всего, никогда не примет.

Однако есть решение, которое может удовлетворить обе стороны. Git имеет git-svnкоманду. По сути, у вас будет репозиторий SVN, но некоторые разработчики могут выбрать собственное локальное репозиторий GIT и синхронизировать его с централизованным репозиторием SVN. Хорошая альтернатива частным филиалам или рассылка некоммитированных патчей. Хорошие инструкции для интеграции с git-svn .

Некоторые из этих ответов значительно устарели в отношении комментариев о GitHub и безопасности из-за изменений в GitHub с момента их публикации.

• GitHub не заставляет вас быть размещенным извне
• Бесплатно версия GitHub является то , что ставит это ограничение на месте.
• Для внутреннего хостинга доступна версия GitHub для предприятий . https://enterprise.github.com/home . Это не бесплатно и стоит $ конечно

Компания, в которой я работаю, только начала использовать ее, и у нас были ТОЧНЫЕ проблемы, потому что наш код является коммерческой тайной, мы находимся в финансовом секторе. Кроме того, есть другие способы использования GIT, которые не включают GitHub, которые похожи, redmine, gitosis и т. Д.

Относительно вопроса «кто его использует»: PayPal, Etsy, rackspace, vimeo, SAP, JPL NASA , ядро ​​Linux

Неопровержимых технических причин слишком много, чтобы перечислять. Единственное, на что стоит обратить внимание - это более масштабные корпоративные проблемы, на которые указывают другие ответы. Самая большая из них, которую я могу придумать, это последовательность, единообразие, четкий аудит, простота аудита. Хотя решение множества проблем со многими из этих других систем VCS является большой проблемой.

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

• Каждый раз, когда мне приходилось использовать SVN в параноидальной среде, например, в торговой фирме, абсурдные зацепки «соответствия» и «безопасности» оказывали огромное влияние на производительность.

Поскольку я размышлял над техническими проблемами использования с точки зрения разработчика, я скажу это. За 15 с лишним лет общего использования я использовал профессиональные системы CVS, SVN, CMVC, clearcase, performance и другие, наряду с GIT. Если бы кто-то хотел, чтобы я использовал что-то другое, кроме GIT (за исключением, возможно, bzr, mercurial, performance и clearcase (в зависимости от настроек двух последних)), я бы сразу понял, что мое время лучше проводить в другом месте. Я почти пришел к такому выводу (хотя и немного расширил возможности CVS и SVN) еще в 2009 году. Я был настолько сыт по горло тем, как SVN использовался на моей работе, я начал использовать GIT в качестве клиента SVN в начале 2010 года, прежде чем помогая убедить нас перейти на GIT.