Существуют ли серьезные компании, которые не используют контроль версий и непрерывную интеграцию? Почему?


17

У моего коллеги сложилось впечатление, что наш отдел программного обеспечения был очень продвинутым, поскольку мы использовали как сервер сборки с непрерывной интеграцией, так и программное обеспечение для контроля версий. Это не соответствовало моей точке зрения, поскольку я знаю только одну компанию, которая занималась разработкой серьезного программного обеспечения и не имела ни того, ни другого. Тем не менее, мой опыт ограничен лишь несколькими компаниями.

Кто-нибудь знает какую-либо реальную компанию (более 3 программистов) , которая занимается разработкой программного обеспечения и не использует эти инструменты? Если такая компания существует, есть ли для них веские причины не делать этого?


3
Эти противные актеры программного обеспечения.
Легкость гонок с Моникой

1
отличаются актеры программного обеспечения от разработчиков программного обеспечения?
Адитья П

"Я не программное обеспечение, но я играю один по телевизору!" - Программное обеспечение актеров.
FrustratedWithFormsDesigner

1
Есть Джейн Сеймур, она серьезная актриса программного обеспечения .... или, по крайней мере, она сыграла Солитар в «Живи и дай умереть» :)
Кевин Д.

3
Там, где я работал десять лет назад, у нас были ночные сборки на всех поддерживаемых системах. Они никогда не приближались к компиляции. Когда-либо.
Дэвид Торнли

Ответы:


5

Я не уверен, что вы назвали бы их серьезным действием, но MySpace довольно бедны в этом отношении: см. Http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill- myspace.html .


1
+1 Они хотя бы в высшей лиге. Я не думал, что это возможно. Такая большая компания без контроля версий. Иди разберись.
Дарамарак

Сумасшедший. Я бы не поверил, но этот блог и ссылки из статьи все надежны.
Стив

Во всем виновата собака.
JeffO

2
Сайт для подростков, начинающих группу в гараже, написан в стиле кодера, работающего из их гаража. Цифры.
Quant_dev

13

Вы будете удивлены, увидев, что реальность может сделать со здравым смыслом ;-)

Я думаю, что есть еще немало компаний, которые не используют систему контроля версий. Интересно, что во всех случаях, которые я видел до сих пор, дело не в том, что они охотно выступают против использования таких систем, а в том, что они не знают, что существует что-то вроде SVN! Что касается меня: я полностью согласен с вами и не могу представить себе ситуацию, в которой я не хочу использовать какой-либо контроль версий. Черт, я даже помещаю свои личные файлы (текстовые документы и т. Д.) С домашнего компьютера в GIT-репозиторий.

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


11
Возможно ли, что средний разработчик программного обеспечения не слышал о программном обеспечении для контроля версий? Откуда эти компании нанимают людей? Темная сторона Луны?
Дарамарак

7
@daramarak: Многие (если не большинство) разработчиков программного обеспечения не читают книги, не просматривают блоги разработчиков и вообще не общаются с другими разработчиками (за пределами их компании). Если вы попадаете в разработку, обучая себя одной из этих книг «Изучите основы языка за 21 день», то вы вряд ли услышите о контроле версий. На самом деле, я не помню, чтобы узнавал о контроле версий в университете всего 10 лет назад.
Джоери Себрехтс

@joeri - к счастью, не правда, где я работаю, но я могу верить в это в целом.
Стив

@perdian - вы говорите «довольно много компаний», но не даете никаких подробностей ... есть ли у вас ссылки на статьи, блоги и т. д. с именами и позором? Я не говорю , что я не верю тебе (на самом деле я действительно верю вам), но данные всегда хорошо ...
Стив

@ Стив Хай - Нет, у меня нет никаких "твердых" доказательств. Я видел несколько компаний , сам, не использовать CI Одера контроля версий (чьи имена я буду держать себя г ) и с немного экстраполяции Я предполагаю , что есть много более «там». Я думаю , что это очень много easiert , чтобы найти компании , которые делают использование CI, просто посмотрев на список ссылок на странице Дженкинс, например. Но наоборот? Не так много людей, рекламирующих «Эй, мы не используем технологию X» ;-)
perdian

12

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

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


3
Я не согласен с тем, что вполне разумно "продолжать идти по этому пути". Да, поставка программного обеспечения в течение последних X лет не означает, что он не будет работать в следующие Y лет без каких-либо изменений. Тем не менее, после внедрения CI в существующие (и достаточно зрелые) программные продукты всегда есть что извлечь из этого выгоду.
Perdian

1
@perdian: всегда есть что выиграть от множества инициатив. Таким образом, вы должны сбалансировать CI со всем остальным. Вы не можете просто утверждать, что КИ дает вам больше пользы, чем все остальное. Вы также должны измерить альтернативные издержки.
RoadWarrior

1
@ SK-logic: RCS был совершенно неизвестен в то время в банковской индустрии Великобритании. И мы разработали несколько очень больших и надежных систем без какого-либо контроля над источниками.
RoadWarrior

1
-1: «Почти каждая компания» - это слишком широкое утверждение, которое неверно. В прошлом году я видел некоторые компании, которые не используют какой-либо инструмент контроля версий, полагаясь на копии версий в общем каталоге. Да, это заставило меня плакать. Они сказали, что «SVN слишком сложно использовать». О, МОЙ БОГ. Но я все еще нахожу некоторые компании, которые такие. Не обобщайте: не все в отрасли знают, что такое система контроля версий, не изучают ничего онлайн и не знают, что такое непрерывная интеграция. (Я согласен, что это ад. Счастлив, что больше не буду там).
Klaim

1
@ SK-logic - ... то, что сказал RoadWarrior, за исключением морской / энергетической промышленности здесь. Я не буду называть имена, но знаю, по крайней мере, две компании, которые являются доминирующими в своем секторе (некоторые специализированные разработки программного обеспечения), для которых я считаю, что никогда не использовал VCS любого типа (в вашем смысле). У них были свои способы отличить хороший код от кода в процессе разработки.
Ладья

7

Просто чтобы указать на ответ @ RoadWarrior:

Я работаю на банк. Я потратил последние 3 года на внедрение контроля версий и теперь смог установить его примерно на 20% нашей кодовой базы (а это довольно много, у нас около 20 разработчиков и мы разработали наши системы в течение> 16 лет)

Через мои контакты в промышленности (Banking), я знаю , что из тонны других финансовых институтов , которые не имеют , что любой нормальный человек назовет управление версиями.

Да, наша индустрия (разработка программного обеспечения) намного печальнее, чем хотелось бы признать.


Мои соболезнования. Похоже, что, по крайней мере, некоторым частям отрасли серьезно не хватает инструментов. Я думаю, что это история о детях сапожников. Могу я спросить, что безумный человек назвал бы контроль версий?
Дарамарак

6
Взять копию кода вручную, прежде чем редактировать его. Например, MyProg -> MyProd.old4
Дэн МакГрат,

К сожалению, эта практика встречается чаще, чем думают люди
Крейг Т

3

Контроль версий: На моей первой работе 25 лет назад не было системы контроля версий как таковой, но это был RSX11 на PDP-11. Тем не менее, был очень высокий уровень контроля качества с официальными проверками дизайна и кода (это было в ядерной промышленности).

С тех пор в каждой работе использовались системы контроля версий, в том числе SCCS, PVCS, clearcase, cvs и performance.

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

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

Я работал в одном месте (крупный банк), в котором для некоторых проектов была установлена ​​КИ, и мы внедрили своего рода систему КИ в нашем проекте, которая действительно облегчила задачу, но заняла около 6 месяцев.


Для мест с унаследованным кодом, они делали автоматические сборки или у них был план сборки / развертывания вручную?
Дарамарак

3

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


3
Абсолютно! Я слышал ответ (или, может быть, мы должны назвать это слабым оправданием) «мы не использовали его до сих пор, и поскольку он работал (каким-то образом), он нам не нужен». Обидно, насколько упорные люди против смены инструментов.
Perdian

1
Я терпеть не могу таких людей; к сожалению, с таким типом «разработчика» я сталкивался слишком часто в своей карьере, и я просто не могу справиться с их невежеством и всегда стремлюсь покинуть компанию, в которой такие разработчики преобладают. Рискуя казаться совершенно враждебным, эти люди - рак этой профессии.
Уэйн Молина

2

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

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

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


1

У моего коллеги сложилось впечатление, что наш отдел программного обеспечения был очень продвинутым, поскольку мы использовали как сервер сборки с непрерывной интеграцией, так и программное обеспечение для контроля версий.

Нет, я ненавижу это говорить, но это правда. Последние два места, где я работал (подразделение банка и финансовая компания), я был тем, кто внедрил систему контроля версий. Ряд мест (особенно магазины, не занимающиеся программным обеспечением) не понимают, почему это действительно необходимо для долгосрочной разработки. Команда обычно начинается с одного или двух человек, а затем растет, хотя и болезненно. С одним человеком или двумя людьми вы можете обойтись (не очень) без этого, потому что вы можете быть почти в постоянном общении друг с другом.

Непрерывная сборка - это совершенно другой случай. Если бы мне пришлось угадывать, я бы поспорил, что почти в 90% мест, где ведется разработка, нет решения CI. Я хожу на конференции, и большинство людей удивляются, что такая организация есть у других организаций, кроме MS или Google. Я обнаружил, что руководство не хочет тратить небольшую сумму денег на его запуск и запуск, даже если это может сэкономить много времени.

Основные причины, которые я нашел для этого:

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

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

Большинство аргументов, которые я слышал от людей, сконцентрированы вокруг лучших практик и т. Д., И они верны, но большинство разработчиков не понимают, что в этом сценарии вы должны сформулировать это с точки зрения финансовой ситуации. С этой суммой денег, которую вы собираетесь потратить, мы сэкономим X времени, и вам понадобятся цифры для ее резервного копирования. Это не всегда так, но это был мой опыт в прошлом.


Я могу себе представить, что подобные проблемы возникают, когда плохая связь от разработчика и выше в руководстве. К счастью, не все компании такие. Там, где я работаю, мы должны (если не обязаны) сообщать руководству, если что-то может сделать нас более эффективными.
Дарамарак

1

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

Непрерывная интеграция? Используйте только если вам это нужно. Для меня всего два программиста, поэтому мы не выиграем от непрерывной интеграции, потому что сами работаем над собственным программным обеспечением.


1
Предполагается, что непрерывная интеграция позволяет выявлять ошибки при их возникновении. Это нужно даже двум разработчикам.
Дарамарак

1
@daramarak: Нет, если два инженера работают независимо над двумя не интегрированными продуктами.
Брайан

1
КИ - одна из тех вещей, без которых я готов обойтись. Лично я хотел бы иметь это на своей работе, но это не произойдет в ближайшее время. У нас есть автоматические сборки 1-2 раза в день, и этого действительно достаточно для наших нужд.
Майкл К

1
С автоматизированной сборкой вы на полпути. Просто зная, что все проверенное в компиляциях иногда может быть радостью («Он компилируется на моей машине»)
daramarak

1

Ха, вы думаете, что вы продвинуты, потому что у вас есть SCM и система CI? Позвольте мне сказать, что это любительский час, когда дело доходит до него.

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

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

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


лол ! подписано: профессионал.
Deadalnix

Я согласен, SCM и багтрекер - это эквивалент разработки брюк для работы. CI - это базовая автоматизация критической функции. Как автоматические резервные копии, но для выпусков. Ах, встречи CCB. Каждую неделю, как по маслу.
Тим Уиллискрофт

1

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

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

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


1

Последняя работа, над которой я работал без контроля версий, была в 2006 году (я веб-разработчик, FWIW). До того, как нанять меня, в компании было всего 2 или 3 разработчика, но я был первым из 10 или около того разработчиков, нанятых всего за пару месяцев. Первое, что я сделал при приеме на работу, - ввел контроль версий (CVS, потому что в то время я не знал, насколько это плохо!), Но многие разработчики, нанятые после меня, не могли заставить его работать над своим разработчиком. среды, поэтому не использовал его. О, я упоминал, что у них даже не было локальных экземпляров приложения? Они взломали код на сервере. И никаких автоматических тестов, конечно. Я съеживаюсь, когда вспоминаю об этом.

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

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

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


«CI - это другое дело. Это здорово, и я это поощряю, но это менее важно, чем контроль версий, по крайней мере, для небольших проектов на интерпретируемых языках ». Согласовано. CI действительно необходим, только когда вы делаете частые и / или сложные сборки, и это начинает занимать много вашего времени, или вы хотите запустить набор тестов, или вы хотите иметь возможность создавать несколько веток и т. Д. Если это В PHP-проекте с дюжиной разработчиков, без набора тестов, и вы переходите к работе один раз в неделю, вы, вероятно, захотите сосредоточиться на хорошем рабочем процессе QA, прежде чем начнете беспокоиться о CI.
Siliconrockstar

И вы, вероятно, захотите сосредоточиться на хорошем тестовом наборе, прежде чем начнете беспокоиться о QA или о чем-то еще.
Марнен Лайбоу-Козер

Может быть, теоретически, но если вы используете программное обеспечение с открытым исходным кодом, если оно не поставляется с набором тестов, это практически невозможно. Я ни разу не работал над PHP-проектом, который имел надлежащее полное тестовое покрытие, но каждый проект, над которым я работал, имел некоторый уровень QA.
silicrockstar

@siliconrockstar Я говорил о том, чтобы иметь хороший набор тестов для вашего собственного кода; Соответствующий уровень тестирования для библиотечного кода - это совсем другое дело.
Марнен Лайбоу-Козер

@siliconrockstar Что бы это ни стоило, большинство Rails-проектов, над которыми я работал, имели превосходное тестовое покрытие для разработчиков (исключения активно пытались его улучшить); не у всех был формальный контроль качества. Гораздо менее необходимо иметь формальный контроль качества с хорошими тестами, хотя это все еще очень хорошая идея. Тем не менее, разработка без тестов невероятно рискованна, поэтому я говорю, что улучшение тестов должно быть приоритетом над чем-либо еще.
Марнен Лайбоу-Козер

0

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.