Який найефективніший / найефективніший спосіб розробити додаток для кількох людей без контролю джерела?

Вступ до моєї ситуації

Я працюю в невеликій компанії з веб-розробок. У нас є команда з чотирьох розробників ASP.NET, включаючи мене. Майже всі наші проекти (> 98%) - це проекти для однієї людини, на виконання яких потрібно приблизно 1-4 тижні. Ми не використовуємо контроль джерел чи версій. Єдине, що у нас є спільна папка на локальному сервері, яка містить останнє джерело (== джерело живої програми) усіх проектів.

У рідкісних випадках, коли нам потрібно працювати над одним проектом з більш ніж однією людиною, ми використовуємо ... Крім порівняння. Один або два рази на день розробники запитують один одного, чи є у них версія, яка компілюється, а потім вони синхронізують свій код за допомогою програми Beyond Compare. Коли над проектом працюють лише дві людини, це працює «досить добре», але як тільки треті розробники вступають у процес, він стає некерованим сміттям. Особливо, коли всі починають вносити зміни в базу даних.

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

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

Пояснення моєї проблеми / проблеми

Через кілька тижнів ми розпочнемо роботу над досить великим проектом за нашими стандартами. Можливо, це займе 2-3 розробника через кілька місяців, щоб завершити його. Я буду керівником проекту (керівником проекту та головним розробником) і буду відповідальним за все. У мене була частка проблем з нашим підходом «Більше порівняння», і я не хочу брати цю дорогу з цим великим проектом, який буде моєю відповідальністю.

Оскільки я сумніваюся, що нам вдасться

• створити власний сервер Git,
• навчити всіх працювати з Git і
• успішно використовувати Git у цьому великому проекті,

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

Оновлення

Я хотів би подякувати всім за відповіді та коментарі. Ось план:

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

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

Це не буде витрачено даремно.

Час , яке ви будете втрачати , коли хто - то переписує або видалення який - то код буде коштувати набагато більше.

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

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

Потім порівняйте це з вартістю отримання контролю над версією - нуля (якщо ви переходите з відкритим кодом) та налаштування її - 3 чоловічих дня.

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

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

Вам ніколи не потрібно просити дозволу, щоб правильно виконувати свою роботу - Сет Годін.

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

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

Відредаговано, щоб додати: Насправді ви задаєте своє запитання: «як мені зробити управління джерелом без використання системи управління джерелом». Ви визнали необхідність, і я думаю, що всі тут справді говорять вам одне і те ж: Немає здорового способу зробити управління джерелом без системи управління джерелом.

У мене є лише ваше резюме, але з цього виходить, що ваш начальник робить аргументи про час і гроші, а ви робите аргумент технічної переваги. Вам потрібно робити аргументи про час і гроші. Вивчіть git спосіб виконання справ і відслідковуйте деякий час, який це може заощадити, а потім подайте журнал своєму начальнику із записами на кшталт "28.03.2011 довелося чекати 30 хвилин, щоб Джо повернувся до складної збірки тож ми могли б зробити об'єднання, команда git merge проти його останнього фіксування склала б приблизно 5 секунд ", з хорошим підсумком внизу.

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

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

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

Це божевільно. Ви повинні використовувати VCS, навіть якщо ви працюєте самостійно. Не використовувати VCS у компанії повинно бути заборонено. Просто зроби це. Негайно! Дійсно ... Вам не потрібні розширені речі з самого початку. GitHub і GitLab дуже прості у використанні, але я впевнений, що ви можете знайти ще кілька сумісних з Windows хостинг-сервісів, якщо ваш начальник наполягає (навіть якщо це не важко налаштувати і використовувати Git в Windows).

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

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

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

Тепер, з моєї точки зору та власного досвіду, я бачу три рішення вашої проблеми:

• Встановіть керування версіями, яке просте у використанні . Раніше я встановлював CollabNetSubversion як SVN-сервер, це досить швидко і просто в налаштуванні, якщо ви зовсім не переймаєтесь безпекою . Якщо ви використовуєте Visual Studio, AnkhSvn може бути встановлений, щоб дозволити розробникам легко оновлювати / вводити вихідний код із Visual Studio.

• Переконайте свого начальника, що тест на Джоела написаний людиною, яка дуже добре знає свою роботу, і якщо тест Джоеля передбачає контроль версій, то на це є вагома причина. Зрештою, він також може вирішити, що розробникам не потрібні засоби виділення синтаксису IDE для написання коду. Блокнот Windows просто чудово, чи не так? А також, навіщо мати доступ до Інтернету? Все, що нам потрібно, - це дуже-дуже старий ПК під управлінням Windows 3.1.

• Покинь цю компанію , оскільки у мене є сумніви, що все, крім контролю версій, там ідеальне та професійне.

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

Будь-який VCS на порядок кращий, ніж його взагалі немає.

Простий спосіб налаштування VCS - це отримання TortoiseSVN (оскільки, здається, ви використовуєте C #, я вважаю, що ви працюєте в Windows). Ви створюєте сховище у вибраній локальній папці (перейдіть до нього, клацніть правою кнопкою миші> TortoiseSVN> Створити тут репозиторій). Поділіться цією папкою у своїй мережі (бажано, щоб вона була на комп’ютері, яка завжди доступна) та зробіть замовлення за допомогою URL-адреси file://computername/path/to/that/repository. Завантаження виключається, налаштування займає не більше хвилини.

Ваша відповідь - це просте посилання на вашого начальника ... надішліть йому цю / її сторінку та виділіть, скільки разів слова «кинути» з’являються у професіоналів.

Хоча слово "німий" з'являється, мабуть, стільки разів, я впевнений, що ваш начальник це не так. Просто йому не зрозуміло абсолютного значення цього. Питання, що його задати, полягає в тому, яке питання, пов’язане з бізнесом, призведе до такої ж відповіді (можливо, бухгалтер пропонує: "Швидше не страхуйте цю будівлю, щоб вас прив’язали до максимуму, це заощадить вам кілька доларів!")

Контроль над джерелами необхідний лише тоді, коли кількість розробників в проекті> 0. Я починаю вважати, що про постійну інтеграцію можна сказати те саме ...

(-:

Оскільки ви розробники ASP.NET, я б запропонував вам скористатися одним із Subversion, TFS або Mercurial - але якщо чесно, не важливо, доки ви хочете з чим-небудь. Розробка без контролю версій не має сенсу - тим більше, коли інструменти більш-менш вільні для розгортання, а витрати на їх використання мінімальні.

TFS забезпечить вам приголомшливий рівень інтеграції. DVCS (mercurial або git), ймовірно, надасть вам найбільшу гнучкість та можливості. Немає вагомих причин НЕ робити цього.

Якби я починав з нуля, це було б майже напевно з Mercurial.

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

Щоб повернутися до початкової точки:

Я буду керівником проекту (керівником проекту та головним розробником) і буду відповідальним за все

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

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

Я б запропонував вам використовувати або Git, оскільки ви вже маєте досвід з ним, або Mercurial, який добре інтегрується у Visual Studio.

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

Ще в мої дні Powerbuilder у нас була ціла команда, яка працювала над набором програм без використання джерела контролю. О, Powerbuilder мав керувати джерелом, але насправді його використання - це марення - якщо PB зазнав аварії, коли ви перевірили файл (і він зазнав аварії LOT), цей власний, двійковий файл вихідного коду тепер був недоступний. У файлі встановлено якийсь прапор, і жодна інша копія ПК не може завантажити його, навіть та сама людина, яка його перевірила.

Тож те, що ми зробили, було досить простим. "Гей, Томе, я буду працювати над xyz.pbl. Тому не вносити жодних змін". У грандіозній схемі речей у нас рідко виникали проблеми.

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

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

Використання DVCS гарантує, що немає необхідності мати сервер і немає складного процесу налаштування. Встановлення Mercurial та вставання та робота з основами повинні зайняти не більше 30 хвилин.

Це не ідеальне рішення, але краще, ніж нічого.

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

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

Ризик

Проблема не в тому, що використання керування джерелами покращує процес розробки. Це більше питання, що станеться, якщо ви взагалі не маєте джерела контролю. Які ризики?

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

Але що станеться, якщо жоден орган не мав резервної копії втраченого файлу? Скільки людей годин би коштувало це виправити? Це може зайняти кілька днів, і це легко підрахувати в середньому за людину годин. Це було б занадто багато для компанії? Чи можна це усунути якось швидше?

Так, з якимсь контролем джерела. На противагу: скільки часу знадобиться, щоб налаштувати контроль версій та створити резервну копію? Більшість відкритих джерел, таких як git або mercurial, не потребують багато часу для налаштування. Навчити людей, як це використовувати, було б не так складно, враховуючи, що ви вже знаєте, як злитися з Beyond Compare, і ви "зареєструєтесь" у загальній папці. Це разова встановлена ​​вартість. Чи були б ці години людини меншими, ніж ризики? Якщо це правда, то використання керування джерелом має бути пріоритетним.

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

Використовуйте розподілену систему управління версіями, як git, і використовуйте спільну папку для зберігання довідкового сховища. Ось чому:

Кожен клон - це резервне копіювання

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

Загальна довідка

Наявність основного сховища з головною гілкою дозволяє знати версію, в якій є останнє слово. Це вирішує "Ви перевірили свої зміни на версії Франка, але чи були у вас і Джона? І як ви їх злили?".

Доставляйте зручніше

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

Поверніться у часі і виправте свої помилки

У вашому ручному злитті виникли проблеми, які ви побачили лише через кілька днів, але ви вже перезаписали вміст своїх спільних папок? Без VSC у вас немає історії, тому ви не зможете легко повернутися до того моменту, коли ви зможете перевірити допущені помилки та виправити їх. Код не як картина, це як фільм: він розвивається в часі. Ви можете витягти картинку з фільму. Ви не можете витягти фільм із картини.

Легше знаходити помилки

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

Кожен розробник несе відповідальність за власну роботу

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

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

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

Хто написав цей код?

Тут є ця помилка, але хто написав саме цей рядок коду? Важко запам'ятати, особливо якщо проект триває кілька місяців. git blameсказав би вам, хто і коли написав цей рядок, тож ви можете запитати потрібну людину, і немає "я не пам'ятаю, щоб це писали".

Проект стає все більшим

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

Термінові зміни

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

Це працювало 10 хвилин тому

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

З системою VCS ви просто зробите щось на кшталт git diffодразу і змінили свою порівняно з правильною версією коду, на якому ви базуєтесь.

Я повинен зберігати свої журнали налагодження

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

Без VCS вам або потрібно скопіювати файли, видалити код налагодження (що може додати деякі помилки редагування), натиснути це і повернути резервні копії файлів. О, але, схоже, якийсь код налагодження все-таки потрапив.

За допомогою git ви просто git add --patchі вибираєте кілька рядків коду, які ви хочете ввести у свій комітет, і можете зробити лише це. Потім ви відновите свою роботу і все ще маєте код налагодження. Вам не доводилося торкатися коду, тому не виникає помилок копіювання / вставки.

Велика кулька грязі

Без ВКС люди працюють на своїй стороні і дають вам купу змін, іноді не пов'язаних між собою. Коли код має занадто багато для перевірки, важко знайти помилку.

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

Якщо я дам тобі 100 картоплин 1 на 1, а одна гнила, ти її негайно знайдеш. Тепер, якщо я скину перед вами 100 картоплин і попрошу знайти гнилу, це не те саме завдання.

Відступ

Сподіваємось, що у вас є хороша політика стилю кодування, інакше зміни відступу зберуть вас з розуму, якщо ви з’єднаєтесь вручну. Звичайно, ви можете ігнорувати пробіли в змінах (але не мовами, коли вважається відступ, як-от Python). Але тоді ви отримаєте дивний код, який важко читати.

Ви керівник проекту

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

Використовуйте дропбокс, він має історію автоматичної версії. Ви можете поділитися папкою "папка" між декількома користувачами.

Редагувати

Ви також можете завантажити TortoiseSVN-клієнт і створити "локальний сховище" на мережевому диску. Тоді люди можуть перевірити вихідний код за місцем розташування папки в мережі.