Чому великі фінансові / страхові компанії повинні використовувати git та / або github

Я працюю на великому підприємстві (30 тис. Працівників) у фінансовій / страховій галузі. Хоча «ІТ» не є нашою основною метою, будьмо чесними, це інформаційно-орієнтована галузь, і компанії з кращими технологічними перевагами, здається, випереджають швидше.

У моїй компанії є багато команд з розробки програмного забезпечення. Вони по всій карті з контролем версій, не кажучи вже про мови / рамки. Деякі не використовують будь-якого (я знаю), деякі використовують PVCS, деякі використовують VSS, а найбільш освічені використовують SVN.

Я хочу принести git на своє підприємство. Більш конкретно, я хочу принести GitHub (приватні сховища). Я знаю правильних людей, щоб поговорити з цим питанням, але будьмо знову чесними, такі різкі кроки, як правило, збиваються на великих підприємствах через неясні проблеми безпеки або того, що ніхто з наших конкурентів не використовує це (і я можу цитуйте лише jQuery, Ruby on Rails, Facebook тощо тощо як посилання).

Тож моє запитання таке. Назвіть найбільш переконливі причини, чому велике підприємство повинно повільно і навмисно переходити від PVCS / VSS / SVN до такого розміщеного рішення git, як GitHub (приватне репо). Звичайно, частина мого плану передбачає участі у довільній участі за несуттєвим проектом розвитку.

Можливо, я зацікавився б декількома речами, як незацікавлена ​​третя сторона. Тож дозвольте мені піднести кілька питань на вас, на які ви краще будете готові відповісти (в ІТ-відділ):

• Будь-яке управління версіями краще, ніж жодне. Нам є з чого вибрати, що з цим погано?
• Розподілений контроль над версіями? Що це? Як ми це контролюємо ?
• Що це коштує? Не тільки програмне забезпечення, але і сервери, ліцензії, обслуговування тощо.
• Я не довіряю GitHub, або будь-якому аутсорсингу хостингу. Нам потрібно все робити вдома. Чому ми не можемо створити власний сервер?
• Чи можемо ми запустити його в Windows? Ми повинні тримати це на нашій нинішній базовій лінії, ви знаєте.
• Як нам забезпечити річ? SVN ми отримуємо, але це мене лякає.

Це найперші питання, які з’являться. Що стосується VSS та PVCS, то, ймовірно, можна придумати купу досить хороших аргументів (наприклад, VSS, що псує історію версій). SVN буде трохи складніше. Я настійно рекомендую зосередитись на можливостях об'єднання GIT, а також рекомендую відкрито думати про Mercurial. Кожен аргумент для GIT також є аргументом для Mercurial - і Mercurial має більш зрілу підтримку Windows.

Безпека має першорядне значення для фінансових та державних установ. Вони будуть надзвичайно стійкі до зовнішніх ресурсів. З точки зору управління ризиками, подумайте, що може статися, якщо хтось зламав GitHub і вкрав вихідний код або виявив вразливість безпеки, зафіксовану в трекері випуску. Це було б руйнівно для компанії. З точки зору чистого менеджменту, якщо компанія є юридичноПотрібно платити вам за кожну працюючу годину, як вони можуть контролювати, чи працюєте ви вдома, коли ресурси знаходяться за межами мережі VPN? З іншого боку, як вони можуть завадити тобі здійснити корпоративний шпигунство, коли всі ресурси доступні за межами компанії? Це аргументи ІТ та управління проти аутсорсингу хостингу. Велика компанія має дивитися на речі таким чином. Для невеликої компанії ви дивитесь на підсумок і скільки коштуватиме розміщення всіх цих послуг.

Насправді більшій компанії дешевше це зробити вдома. У них вже є ресурси ІТ, їм просто потрібно трохи змінити обов'язки. І якщо рішення багато в чому дбає про себе, потребуючи лише періодичного обслуговування (резервного копіювання та управління користувачами), тим більше причин тримати його всередині корпоративних дверей.

Що стосується хостингу Windows, то це організація за організацією. Кілька компаній проковтнули коолайд Windows. Інші проковтнули коолайд Linux. Інші розглядають це в кожному конкретному випадку. Вам доведеться грати за правилами, які ІТ-відділ встановив для вашої організації. Поки ваше рішення може бути розміщене на будь-якому, ви золоті.

Нарешті, у такій великій організації гарантовано знайдуться фефери, які все хочуть робити так, як вони. Всі вони мають переконливі аргументи, чому вони обрали VSS, PVCS, SVN чи що у вас є. Для ІТ вони всі однакові. Єдиний спосіб консолідуватись у організації, яка є великою, - це порядок звернення через фіат згори. Такі замовлення завжди зустрічаються з опором, і, мабуть, це не те, що ваша компанія хоче зробити, якщо тільки очевидні переваги загальної вартості власності (TCO) від стандартизованої системи контролю версій.

Я також працюю на фінансовому / страховому підприємстві (хоча і не таке велике, як те, в якому ви зараз працюєте). У нас також є декілька команд розробників, і хоча підприємство обрало спеціально продукти для мікрософт для розробки, досі немає головного архітектури, контролю мови та джерел. Всі ми використовуємо .Net, але у нас є кілька проектів у різних версіях фреймворку та на різних мовах. Деякі проекти використовують VSS, інші - TFS. Зараз у нас є новий архітектор вищого рівня в якості менеджера з контролю якості, і він очолив перехід на підприємстві від нашого відстеження помилок у хадж-підзі, управління джерелами, використання фреймворку до більш універсальної реалізації TFS для всіх. Це стає можливим лише завдяки тому, що він a) надзвичайно досвідчений у роботі програмного забезпечення,

Вирішуючи це у власній організації, ви повинні спочатку розглянути деякі речі:

1. Чому ви так закохані в GitHub як відповідь? Ви шукаєте загальний контроль над джерелами або шукаєте причину, щоб реалізувати щось, що вам зручно? Я не знаю відповіді (і, чесно кажучи, не байдуже), але це питання, яке виникне, коли ви почнете гуляти у справах інших людей.
2. На даний момент ви пов’язані з однією з цих програмних команд? Якщо так, то, можливо, вам знадобиться знайти непідвладненого, добре розташованого особи, щоб відстоювати цю концепцію. Інакше інші команди розвитку можуть просто відчути, що ви намагаєтесь накладати на них своє мислення. Це зробить їх ще більш стійкими до концепції, оскільки вони вже мають щось, що працює (на їхню думку).
3. Чи доклали ви жодних контактів з особами інших команд, щоб отримати бай-енд на цю концепцію? Чи мають інші розробники подібні думки чи сумніви? Ще одним напрямком для досягнення цієї мети є створення критичної маси для людей, які виконують цю роботу. Оскільки все більше людей починають вимагати спільного сховища джерел, керівництву доведеться помітити це.
4. Чи достатньо ви знайомі з кодом / процесами / вимогами інших команд, щоб сказати, що GitHub буде (або не буде) працювати на них?

Що стосується вашого остаточного (чи фактичного?) Питання, то єдиною справжньою переконливою причиною з точки зору керівників бізнесу є те, що це економить гроші. Ці заощадження можуть бути у вигляді скорочення часу простою, підвищеної безпеки коду, підвищення продуктивності розробника, збільшення надмірності бази коду (для резервного копіювання) тощо, тощо. У кінцевому рахунку вам потрібно буде переконати людей, які пишуть чеки на все це, що час, зусилля та гроші, витрачені на перехід на таку модель, цілком заслуговують цього, зрештою, як окупність своїх інвестицій. Вам також потрібно буде показати, що майбутня підтримка цієї самої моделі знайдеться тоді, коли нарешті відбудеться "повільно та свідомо".

Дуже багато, що вкладається в таку корпоративну зміну в доктрині, тому знадобиться багато ентузіазму в стилі "нижнього", і вам точно знадобиться хтось на рівні ВП, щоб відстоювати цю концепцію. Менеджер може працювати, але керівник матиме набагато більше повноважень для друку концепцій для інших груп.

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

GitHub - ще більш проблематично. Це зовнішня послуга. Вихідний код у зовнішній службі - це те, що керівництво, швидше за все, ніколи не прийме.

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

Деякі з цих відповідей істотно застаріли щодо коментарів щодо GitHub та безпеки через зміни в GitHub з моменту їх публікації.

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

Компанія, в якій я працюю, щойно почала її використовувати, і ми мали ТОЧНІ ж побоювання, оскільки наш код є комерційною таємницею, ми перебуваємо у фінансовому секторі. Окрім цього, існують інші способи використання GIT, які не включають GitHub, подібні, червоний камінь, гітоз тощо.

Щодо питання "хто цим користується": PayPal, Etsy, стійка, vimeo, SAP, JPL NASA , Linux Kernel

Вагомих технічних причин тут занадто багато. Єдине, на що варто звернути увагу, - це великі проблеми великих підприємств, на які вказують інші відповіді. Найбільше, про що я можу придумати, - це послідовність, однаковість, чіткий аудит, простота аудиту. Хоча вирішення скарбниці проблем з багатьма цими іншими системами ДКС є великим.

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

• Кожен раз, коли мені доводилося використовувати SVN в параноїдальному середовищі, як торгова фірма, абсурдні гачки "відповідності" та "безпеки" були настільки надзвичайно згубними для роботи.

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