Кількісне визначення переваг сучасної системи управління версіями [закрито]

Я працював керівником / розробником команди у великому фінансовому середовищі протягом більшої частини трьох років. Наш процес випуску виробництва - це кошмар, оскільки він обертається навколо Clearcase. У нас є група з управління змінами, яка виконує всі випуски і яка дозволить вводити код лише у виробництво, яке було взято з нього.

Однією з перших речей, які я зробив, коли я приєднався, було налаштувати свою команду з Git. Усі погодились, що Clearcase жахливий і недоцільний для повсякденного вирішення питань контролю джерел. Таким чином, ми створили своєрідне "неофіційне" сховище на моїй локальній машині, і я написав сценарій, щоб синхронізувати наші репозиторії git та Clearcase протягом часу випуску.

Слова про це поширилися на інші команди та декілька людей прийняли той самий процес. Використовувати git "неофіційно" для щоденних заходів та "офіційно" використовувати Clearcase для випусків. Я став подібним до переходу до хлопця з будь-якими проблемами з Git.

Отож, у мене на цьому тижні зустріч із SVP щодо зміни інфраструктури, яка спеціально хоче, щоб я пояснив їй достоїнства Git. Слово, мабуть, дісталося їй моїх частих мітингів на Clearcase. Якщо вона прийме мої аргументи, я по-справжньому допоможу своєму роботодавцеві позбутися від цієї гидоти.

Мій досвід роботи з керівниками говорить про те, що вони хочуть надзвичайно коротких пояснень для всього б) цікавляться лише фактами, що стосуються цифр долара

Розробнику я можу пояснити переваги Git over Clearcase (або БУДЬ-яку іншу систему управління версіями над Clearcase з цього приводу), але я малюю порожню інформацію про те, як це зробити технічному керівнику без технічного досвіду (у неї є MBA і зробив її ступінь з географії).

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

Я намагаюся знайти конкретні факти, що демонструють, що розробники ефективніше працюють з Git або будь-якою сучасною системою управління джерелами.

Я думаю, що факт, що інші команди почали використовувати Git внутрішньо, є значущим знаком, але він все ще недостатньо сильний, оскільки його все одно можна відхилити як особисту перевагу.

Мені дійсно потрібно щось потужне, щоб прорватися через "Цей процес працював 20 років, чому ми повинні його змінювати?" аргумент.

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

Ви кажете "цей процес працював 20 років", але чи справді це? По-перше, виклавши, що ви маєте на увазі під нашим "процесом випуску виробництва - кошмар". Створіть список проблем із поточним процесом / інструментом, який є максимально активним для ClearCase.

Потім створіть список "рішень" процесу / інструменту, які є максимально агностичними для Git (хоча Git або будь-який сучасний DVCS точно сподобається законопроекту). Пояснення, чому Git кращий за ClearCase, нічого не означає для користувачів, які не користуються.

Дозвольте команді інфраструктури підтвердити, що поточний підхід має проблеми, які ви визначаєте. Це, ймовірно, змусить їх звернутися за підтримкою до IBM, щоб "виправити" ці проблеми. Залишайтеся підключеними, щоб гарантувати, що IBM не стоїть на шляху вирішення проблем. Оскільки ClearCase не має основних властивостей нашого сучасного розуміння контролю версій, більшість цих проблем неможливо виправити або потребуватиме значних змін інфраструктури.

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

Удачі!

Наш процес випуску виробництва - це кошмар, оскільки він обертається навколо Clearcase. У нас є група з управління змінами, яка виконує всі випуски і яка дозволить вводити код лише у виробництво, яке було взято з нього.

Ні, ваш процес є "кошмаром" через вашу групу управління змінами та процедури звільнення. Вперед і замініть Clearcase на SVN або git або Fossil. У вас будуть точно такі ж проблеми . (Я думаю, що вони роблять це правильно TBH, важливий сильний контроль випуску).

Це те, на що потрібно зосередитись, а не примхливі повноваження git (які не стосуються всіх, окрім чортів), вам потрібно зосередитись на діловому випадку, щоб змінити процес, щоб зробити його менш обтяжливим. Швидше за все, ви можете це зробити за допомогою Clearcase, але це дає вам можливість підкрастись ідеєю використання git у будь-якому випадку.

Якщо ви не дивитесь на "велику картину" тут, найкращий випадок, коли ви отримаєте це, щоб використовувати git з тими ж обмеженнями, які вимагає група випусків. Якщо ви розглядаєте більш широкі аспекти того, для чого призначений контроль змін, тоді ви оціните обмеження, які вам доведеться застосувати, щоб зробити git корисним у вигляді сильно контрольованого процесу випуску, який потребує ваш орган.

Деякі ідеї для вас: запропонуйте їм бачити проблеми продуктивності в поточній системі з точки зору розробника. Зробіть це як частина 1 з 2. Частина 2, займіться роботою з ними над випуском, щоб ви могли побачити проблеми управління, які вам потрібно зрозуміти розробникам. Ставтесь до цього як до навчальних вправ для обох сторін, щоб переглянути погляд іншої сторони, і тоді ви повинні мати змогу придумати рішення, яке все ще вирішує основні вимоги будь-якої сторони. Зауважте, що випуски важливіші за розробники, тому ви повинні бути тим, хто готовий дати перевагу більше, ніж ви їх очікуєте.

Після того, як ви дізнаєтесь, що потрібно для випусків, вам слід погодитись написати детальний документ із процесом (із детальними деталями), який ви зможете показати їм, надаючи їм те, що їм потрібно. Як ви можете масажувати це, щоб стороною розробника було краще для вас, залежить від вас. Я думаю, що їм не дуже важливо, як розробник робить Dev, якщо джерело належним чином керується та випускає правильно організовано - це означає, що вам доведеться показати, як зміни коду можна прив’язати до зміни квитків, як взяти код, який було зроблено випуск для виправлення, складання та повторного випуску.

Конкретні приклади вражають більше, ніж абстрактні переваги. Я думаю, що ви отримаєте найбільший успіх, якщо зможете задокументувати конкретні приклади, коли (a) Clearcase спричинив проблеми, для вирішення яких потрібен час, і (b) Git вирішує ці проблеми. Пам’ятайте, що вам не потрібно вникати в технічні деталі, чому це так (якщо не запитують), просто покажіть, що це так; керівництву не потрібно знати технічні характеристики, за це вам платять.

Якщо ви можете прикласти до цих прикладів певні часові шкали та дати, тим краще. Можливо, ви також зможете доповнити це, показавши, що завдання X, що ви багато займаєте, займає Y хвилин у Clearcase, а Z хвилин у Git.

Пам’ятайте, що час - це гроші, тому якщо ви зможете показати, що робота з Git швидше, ви можете показати, що це також матиме фінансовий сенс.

Ось спроба, як би я спробував це.

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

"Якщо чарівна річ вже працює, навіщо ризикувати її порушити?"

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

Я б почав з того, що git зараз широко використовується. Використовуйте номери, як-от такі: http://ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/

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

Також менеджер насправді не може бути звинувачений у дотриманні основних речей, чи не так? На відміну від того, хто тут використовує $ other_cvs?

Поставте акцент на тому, як великі проекти використовують його, тому що це прості, швидкі, гнучкі, потужні… Знайдіть великі проекти з великими іменами, що додаються до нього (GNU / Linux, Google, Microsoft ...), які використовують git.

Продемонструвавши, що це не може бути поганим кроком, ви можете перейти до того, як це покращить справи у вашому випадку.

Ви хочете, щоб компанія залишалася конкурентоспроможною, а не була випереджена швидшими, більш спритними командами, правда? Я б спробував знайти деякі внутрішні (письмові) оцінки того, як змінилася продуктивність, використовуючи Clearcase vs Git. Ви можете скористатися допомогою колег-розробників. Потім екстраполіруйте для всієї компанії (тобто всіх розробників програмного забезпечення) з номерами та орієнтовною вартістю перебування в Clearcase.

Я б навіть, якщо доречно, повторно сформулював це все в письмовій електронній пошті після зустрічі (включіть потрібних осіб).

Мені дійсно потрібно щось потужне, щоб прорватися через "Цей процес працював 20 років, чому ми повинні його змінювати?" аргумент.

Це неправдивий аргумент (кінні вагони "працювали століттями", але ви, напевно, хочете придбати машину замість цього).

Я чув той самий аргумент щодо svn vs. mercurial (я використовував mercurial у своїй системі розвитку).

Ця проблема полягає не в заміні того, що працює; Не намагайтеся охарактеризувати це як таке, і якщо це питання, яке вам потрібно "перемогти", то слід почати, вказавши, що це не питання того, що працює чи ні - а питання про те, які переваги у вас з git , коли обидва працюють (і чому git працює краще).

Хороші аргументи для використання git:

• git - це зміна націлена замість файлу. Це означає, що зміни легше відстежувати через файли (відстеження через проект).

• git поширюється замість централізованого; Це означає, що перевірка матеріалів не обмежена швидкістю мережі - заощаджуючи багато часу. Це також означає, що у вас немає жодної точки відмови, якщо ваш сервер ClearCase знизиться.

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

Я думаю, що факт, що інші команди почали використовувати Git внутрішньо, є значущим знаком, але він все ще недостатньо сильний, оскільки його все одно можна відхилити як особисту перевагу.

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

Отож, у мене на цьому тижні зустріч із SVP щодо зміни інфраструктури, яка спеціально хоче, щоб я пояснив їй достоїнства Git.

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

Мені дійсно потрібно щось потужне, щоб прорватися через "Цей процес працював 20 років, чому ми повинні його змінювати?" аргумент.

Важко по-справжньому судити, що було б хорошим аргументом, не будучи свідком події. Але я спробую допомогти вам сформулювати ваші аргументи, щоб їх можна було почути.

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

• Які нові можливості принесуть це? Чи є щось, що ми зараз не можемо зробити, що ми хотіли б зробити, і що це дозволило б нам це? Почніть з позитивної ноти.

• Який вплив на графіки випусків? Яка вартість впровадження цієї зміни до наступного випуску? Які витрати та вигоди від наступних випусків?

• Чи це спричинить за собою зміну процесу? Чи не потребуватиме ця зміна від розкладу випуску, щоб люди в процесі випуску змінили свій шлях? Чи буде це прозорим для них, чи їм потрібно буде адаптуватися? Вам потрібно буде співпрацювати з іншими відділами? Люди стійкі до змін.

• Чи є неминуча небезпека дотримуватися чинної системи? Чи є у поточному процесі залежність від програмного чи апаратного забезпечення, яка минула або скоро закінчиться? Чи покладається вона на спеціалізовані знання від осіб, які збільшують витрати на найм? Чи є у нього потенційний отвір у безпеці, який підключає нова система (бонусні бали, якщо цей отвір може призвести до судових дій)? Не махайте рукою чи не "можливо" чи "ймовірно" це: сенс полягає в тому, що він працював добре протягом 20 років, тому тягар доказування лежить на прихильнику змін.

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

Ви можете знайти цю відповідь, щоб переконати компанію, над якою працюю, щоб впровадити контроль версій? корисний.