Использование git (или другого VCS) в вашей компании - PullRequest
4 голосов
/ 20 сентября 2009

Некоторые мои друзья и я недавно говорили о контроле версий и о том, как они используют VSS на своих рабочих местах, и, вероятно, скоро уйдут от этого. Один из них сказал, что его компания, скорее всего, будет использовать Team Foundation Server.

В конце концов, разговор дошел до разговоров о некоторых VCS с открытым исходным кодом, включая git и SVN. Никто из нас на самом деле не знал ни о каких компаниях, которые используют обе из них внутренне, хотя мы предполагали, что некоторые из них сделали это для SVN, но мы не были слишком уверены в git. Я использовал Google и Android, используя его, но мой друг решил, что это только для общедоступного исходного кода, и что они могут использовать что-то другое для внутренних проектов.

Очевидно, что это больше, чем просто SCM, делает TFS настолько интригующим:

  1. Специалисты по продажам и поддержке Microsoft (хотя мой друг и говорил своим менеджерам кое-что, что, по его мнению, могло вводить в заблуждение со стороны MS)
  2. Интеграция вещей за пределами SCM, включая управление проектами (я просто выясняю, что есть и такие же вещи для git)
  3. Опять же, это Microsoft, и переход с VSS на TFS кажется логичным (или нет?)

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

Вы думали об этом и решили против этого? Любая причина почему?

Ответы [ 8 ]

6 голосов
/ 20 сентября 2009

Мы используем git для всего нашего исходного кода. Это просто имеет смысл.

  • Нам практически невозможно что-либо потерять, поскольку в момент, когда два человека касаются проекта, у нас есть три полных его копии (и наши резервные копии этих репозиториев).
  • Мы не полагаемся на какую-либо централизованную инфраструктуру, включая сеть. Я работал над проектами в туннелях BART.

В теории эти коммерческие системы должны спасти вас от сломанных репозиториев и всевозможных чудесных вещей с их поддержкой.

В практике Я потерял больше кода и времени для централизованных репозиториев, чем распределенных.

3 голосов
/ 20 сентября 2009

По сути, при хранении важного кода в хранилище предприятие будет учитывать один конкретный момент:

Какой поддержки он может ожидать от компании, которая использовала VCS, когда хранилище рухнуло, каким-либо образом повреждено или нуждается в анализе?
Есть ли SLA (Соглашение об уровне обслуживания), которое поставляется с ним?

Вы редко будете иметь это с продуктом с открытым исходным кодом, и он вам не всегда нужен (поскольку у вас есть доступ почти ко всему - продукту с открытым исходным кодом)

Есть и другие аспекты, которые необходимо учитывать, прежде чем мы перейдем к части «интеграция с другими инструментами»:

  • административные расходы
  • затраты на резервное копирование (хранилище должно быть заблокировано или отключено для резервного копирования в согласованном состоянии?)
  • скорость и общие характеристики общего задания
  • Кривая обучения продукта
  • и т.д ...

Все эти моменты могут повлиять на решение в пользу коммерческого решения или решения с открытым исходным кодом.


Редактировать: только для информации, я только что нашел это на CM (Управление конфигурацией, файл PDF) , который имеет несколько хороших аргументов за или против коммерческого инструмента. (7.4 Общее обсуждение, стр. 98-99)

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

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

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

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

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

Примечание: вышеизложенное не является "абсолютной" истиной, и может быть найден некоторый контрпример, но я считаю, что общий аргумент имеет свои достоинства, и я добавляю его здесь, чтобы другие могли его увидеть.

3 голосов
/ 20 сентября 2009

Вопрос должен быть вики сообщества, и он субъективен.

Мне кажется, все дело в интеграции. TFS - это больше, чем просто контроль версий, и он хорошо интегрирован? в стек MS. Если вы MS House, то это логичный выбор.

философия открытого исходного кода обозначает подход «фильтра» или «многоразового использования, малых компонентов» к проектированию систем ... и систем систем ... если вы хотите заменить TFS или какое-либо другое решение, тогда вам потребуется интегрировать SVN, git или любую другую VCS в ваше решение.

MS вещи работают из коробки для ассортимента продуктов MS. С открытым исходным кодом у вас есть выбор ... но вам может понадобиться интегрировать его в другие вещи (например, bugzilla), чтобы получить сопоставимое решение. Выбор хорош; но это зависит от того, занимается ли ваша компания разработкой программного обеспечения для клиентов или тратит время и деньги на собственные решения.

1 голос
/ 18 февраля 2016

Многие компании используют инструменты с открытым исходным кодом, такие как Mercurial, Git или SVN. Там, где я работаю, мы почти исключительно используем SVN, несколько лет назад мы переехали ClearCase .

Многие из этих инструментов проще, более легки, более настраиваемы и лучше поддерживаются, чем их коммерческие конкуренты. Кроме того, многие новые сотрудники уже знакомы с Mercurial, Git и даже Subversion по работе с открытым исходным кодом или в школе. Вы действительно не можете ожидать того же от программного обеспечения, которое стоит 4000 долларов за пользователя.

Если вы беспокоитесь о поддержке, есть компании, которые делают бизнес, поддерживая (и размещая) открытый контроль версий. Я думаю о Fog Creek's Kiln , Atlassian (которому принадлежит BitBucket ) и, конечно, GitHub в меньшей степени (когда-либо Интересно, кто на самом деле покупает многопользовательские платные планы GitHub ? Да ... предприятия тоже используют git.)

1 голос
/ 20 сентября 2009

Как консультант я работал с несколькими клиентами (некоторые довольно крупные имена, такие как Baker Hughes), которые используют Subversion в качестве системы контроля версий (обратите внимание, что некоторые команды работали над TFS). Я даже использовал его у предыдущего работодателя (переключился с VSS на SVN).

Что касается Git, я еще не видел, чтобы слишком много компаний использовали его для внутреннего использования, и я сомневаюсь, что вы это сделаете, пока не появятся лучшие интерфейсы Windows для него. Я слышал, что такие вещи, как Git Extensions и TortoiseGit становятся намного лучше, и я слышал о людях, имеющих большой успех с этими инструментами, но они не использовали их в большой компании.

1 голос
/ 20 сентября 2009

Я не думаю, что философия разработки git и DVCS в целом привлекательна для крупных компаний - центральный репозиторий имеет для них гораздо больше смысла (и на самом деле может работать лучше для централизованных организаций).

Я работаю в крупной ИТ-компании в банковском секторе; они мигрировали из CVS в SVN только 2 года назад, следуя очевидному пути обновления.

0 голосов
/ 21 февраля 2018

Я работал разработчиком во многих различных компаниях (краткосрочные контракты и более длительная работа). На каждой работе, которую я имел с 2009 года, использовался Git (до этого я использовал SVN и CVS). Я бы не стал возвращаться к нераспределенной VCS на этом этапе.

0 голосов
/ 21 сентября 2009

Вот мои данные: в последнее десятилетие я работал с компаниями, которые использовали

  • нет VCS
  • ВСС
  • CVS
  • 1010 * SVN *
  • мерзавец

примерно в таком порядке. Некоторые компании использовали несколько из них за эти годы (я предложил и выполнил некоторые переходы), одна компания, которая перешла с SVN на git, сделала это, когда я уходила, сначала использовав ее для библиотеки, которую они выпустили как Open Source.

...