Чи є серйозні компанії, які не використовують контроль над версіями та постійну інтеграцію? Чому?

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

Хтось знає про будь-яку реальну компанію (більше 3-х програмістів) , яка працює в програмному бізнесі і не використовує ці інструменти? Якщо така компанія існує, чи є якісь вагомі причини для них цього не робити?

Я не впевнений, що ви б назвали їх серйозним діянням, але MySpace на цьому фронті досить бідний: Дивіться http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill- myspace.html .

Ви були б здивовані, побачивши, що реальність може зробити здоровим глуздом ;-)

Я думаю, що все ще існує досить багато компаній, які не використовують систему контролю версій. Цікаво, що в усіх випадках, які я бачив до цього часу, це не тому, що вони охоче виступають проти використання таких систем, а тому, що вони не знають, що існує щось на зразок SVN! Що стосується мене: я повністю згоден з вами і не можу уявити ситуацію, коли я не хочу використовувати будь-який контроль над версіями. Чорт, я навіть заношу свої власні особисті файли (текстові документи тощо) на домашньому ПК у сховище GIT.

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

Практично кожна компанія в моїй галузі (банківська справа) зараз використовує контроль версій. Але, безумовно, можна успішно розробляти програмне забезпечення без контролю версій. 20-30 років тому. ми зробили саме це.

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

Просто щоб поставити зустрічну точку на відповідь @ RoadWarrior:

Я працюю в банку. Останні 3 роки я провів реалізацію контролю версій, і тепер мені вдалося отримати його приблизно на 20% нашої кодової бази (що досить велике, у нас є близько 20 розробників і розробили наші системи протягом> 16 років)

Через мої контакти в промисловості (Banking), я знаю , що з тонни інших фінансових інститутів , які не мають , що будь-яка нормальна людина назве управління версіями.

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

контроль версій: У моїй першій роботі 25 років тому не було системи контролю версій як такої, але це був RSX11 на PDP-11. Однак був дуже високий рівень контролю якості з формальними переглядами дизайну та коду (це було в ядерній галузі).

Кожна робота з тих пір використовує системи управління версіями, включаючи SCCS, PVCS, прозорий куточок, відеоспостереження та perforce.

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

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

Я працював в одному місці (великому банку), в якому було створено CI для деяких проектів, і ми впровадили своєрідну систему ІС на нашому проекті, яка значно полегшила роботу, але на це пішло близько 6 місяців.

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

Хоча я зараз працівник, я раніше працював самозайнятим в якості консультанта по базі даних. Протягом цих багатьох, багатьох років я був у десь від 800 до 1000 компаній, від рівня мами до попти до Fortune 100.

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

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

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

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

Безперервна збірка - це зовсім інший випадок. Якби я мав здогадуватися, я би ставку, що майже 90% місць, де займаються розробкою, не мають рішення CI. Я ходжу на конференції, і більшість людей вражені тим, що організація, крім MS чи Google, має її. Що я з’ясував, це те, що керівництво не хоче витрачати невелику суму грошей, щоб підняти його та працювати, хоча це може зекономити багато часу.

Найбільші причини, які я знайшов для цього:

1. Люди в управлінні піднялися через ряди в одній організації. Вони ніколи не використовували і не потребували цього, навіщо їм зараз змінюватись? Деякі, кого я знайшов, просто бояться змін. Щось нове - це страшно, і це заважатиме їм пилити старий компілятор і допомагати нашим молодшим вчасно потребувати. В інших випадках (і частіше) у них є бюджети, які завжди тісні, і вони повинні приймати рішення про те, куди витрачати гроші. Для нас реалізація цих питань очевидна потреба, але це тому, що ми ними раніше користувалися. Ми знаємо переваги, вони не мають.

2. Менеджери - люди, які не є ІТ, і тут все, що ви хочете витратити гроші на те, що раніше не було потрібно.

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

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

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

Га, ти думаєш, що ти просунувся, тому що ти маєш SCM та систему CI? Дозвольте сказати вам, що це година любителя, коли справа доходить до неї.

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

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

Я працював у кількох компаніях, і не можу придумати жодної, яка б не мала якоїсь форми СКМ. Деякі з них були більш вичерпними, ніж інші, але всі вони мали систему, яка добре працювала для них, навіть ті, що використовували VSS.

Навіть з двома програмістами, коли ви працюєте над складними програмами та списком завдань, важко не перешкодити змінам один одного.

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

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

Остання робота, над якою я працював без контролю версій, був у 2006 році (я веб-розробник, FWIW). У компанії було лише близько 2 або 3 розробників, перш ніж мене найняли, але я був першим з 10 або більше розробників, найнятих всього за пару місяців. Однією з перших речей, які я зробив, коли взяли на роботу, було запровадити контроль над версіями (CVS, тому що я тоді не знав, як це погано смоктало!), Але багато розробників, найнятих після мене, не змогли змусити його працювати над своїм розробником середовища, тому не використовував його. О, я згадав, що вони навіть не мали запущених локальних примірників програми? Вони зламали код на сервері. І ніяких автоматизованих тестів, звичайно. Я плачу, коли думаю про це.

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

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

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

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