Subversion / Source Control только для производственного кода?


21

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

Это нормальная практика? Мне кажется, что мы теряем много преимуществ контроля версий, в том числе:

  • Детальное отслеживание хода проекта
  • Отслеживание проблем по мере их появления и решения
  • Легко откат ошибок
  • Простое резервное копирование кода, поэтому мы не потеряем много, если рабочая станция выйдет из строя
  • Проще точно определить, какой код выполняется на каких рабочих сайтах, если мы помечаем исправления в исполняемые файлы, как описано здесь
  • Простое сотрудничество (хотя мы не делаем никакой командной работы; это все сольные проекты)
  • И т.п.

РЕДАКТИРОВАТЬ: Я должен подчеркнуть, что исторически, в этой компании не было никакой настоящей командной работы; всего два разработчика работают над отдельными проектами. Кроме того, многие проекты небольшие, поэтому они могут быть завершены в течение нескольких недель. И компания была в бизнесе более десяти лет и прекрасно обходилась без контроля источников. Проекты обычно завершаются в установленные сроки.


2
Как он мотивирует эту идею, кстати? Если он не дал вам никаких причин, вы спросили?
Анто

8
"Джо" понимает Ветвление? Некоторые нежные вопросы, которые нужно выяснить, могут быть интересными.
Джеймс

2
@ Анто - я думаю, что лучше всего подытожить это "это не производство и не должно быть частью производственного репозитория".
Мистер Джефферсон,

1
@ Джеймс - я не думаю, что он знает SVN в целом очень хорошо, так что нет, я не думаю, что он знает о ветвлении. Но, учитывая ответы ниже, я думаю, что это решение.
Мистер Джефферсон,

4
Прочитайте этот вопрос и тихий голос в моей голове просто закричал "НОООООООООООООооооооооооооо".
Кевин Д

Ответы:


1

Если проекты завершены в установленные сроки, можно ли предположить, что клиенты являются счастливыми клиентами? :)

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

Если вы уверены, что организация и контроль кода могут помочь вам и вашей команде внутренне, тогда SVN следует рассмотреть, ИМХО. Вы получаете бонусные баллы, если этот маршрут действительно работает, и компания способна производить продукцию более высокого качества, тем самым делая счастливых клиентов!

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

Будьте уважительны, и вас могут услышать.

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


42

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


6
Пожалуйста, подчеркните проблему разветвления и пометки. Это - я думаю - важная особенность, которая заставляет людей настаивать на производстве только в SVN.
С.Лотт

3
отличная точка зрения, даже с вашей склонностью к водке.
Ковар

Довольно много? Я бы сказал, что он совершенно неправ. Нет вопросов об этом.
Стивен Эверс

2
@Covar: я не загрязняю свою водку вермутом :)
Wyatt Barnett

22

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

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

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


12
Но он не опытен в работе в качестве члена команды.
Ладислав Мрнка

2
@ Том Хэмминг: код резки не разрабатывает программное обеспечение. Я уверен, что он хорош в программировании, но в наши дни контроль версий больше не «инструмент», как IDE. Конечно, технически вы можете обойтись без этого, но никто в здравом уме не делает.
Стивен Эверс

2
@SnOrfus - Хотя я до некоторой степени согласен с полезностью SCM, моя цель в этом вопросе не состоит в том, чтобы опрокинуть Джо и / или его навыки разработчика. Опять же, у него получился отличный продукт, он хорошо осведомлен, и он отлично обходился без SCM в течение последних 10 лет. Моя цель с этим вопросом состояла в том, чтобы увидеть, была ли его точка зрения широко распространенной, с которой я просто не сталкивался; В конце концов, я только что окончил школу и относительно неопытен в этой отрасли. В любом случае, я верю, что он честно хочет обеспечить качество и надежность рабочего процесса.
Мистер Джефферсон,

3
@ Том: Я могу сказать вам прямо сейчас, что независимо от того, что вы думаете о качестве его работы, он не является опытным разработчиком, если он не знает, как правильно использовать контроль версий. Другого варианта нет, кроме того, что он может работать один в подвале. Даже в моих собственных проектах, где я являюсь единственным разработчиком, я в полной мере использую контроль версий.
Иордания,

5
@SnOrfus: я могу работать очень счастливо без IDE. Я не буду работать без контроля версий. Если команда не использует это, я буду управлять этим самостоятельно.
Кевин Клайн

12

Оставляя в стороне вопрос о том, прав Джо или нет (кстати, он неправ), мне кажется, что компромисс может быть достигнут, если вы используете распределенную систему контроля версий, такую ​​как Git или Mercurial .

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


1
Я подумал об этом и провел небольшое расследование (и услышал хорошие вещи), но моя нерешительность заключается в том, что мы уже приобрели и установили VisualSVN Server, и ни у кого из нас нет опыта работы с Git или Mercurial. , Это будет еще более трудная битва, если я попытаюсь убедить всех, что нам нужно купить больше программного обеспечения и / или отбросить существующие инвестиции. Но хороший момент.
г-н Джефферсон

3
@Tom: Если это должен быть Subversion на внутреннем сервере, вы можете использовать слой совместимости Git или Mercurial Subversion для вещей, которые не готовы к производству, и перевести работу в Subversion, когда она будет готова.
Кен Блум,

2
@Tom Hamming: я переключаюсь с SVN на GIT почти год назад. После некоторого ругательства я начал любить его (хотя в Cygwin он работает не так хорошо, как в Linux). Я никогда не тратил на это денег, я вполне доволен командной строкой и двумя бесплатными инструментами. Я даже не работаю, чтобы интегрировать его в мою среду разработки (затмение). YMMV, но если бы я был на вашем месте, я бы использовал свое личное git-репо и git svnдля взаимодействия. Вам не нужно ничего покупать и вам не нужно никого убеждать; им даже не нужно знать.
Maaartinus

1
@ Том Хэмминг: как индивидуальный разработчик, вы можете регулярно git pushвносить изменения на другой компьютер (в качестве резервной копии). Это не обязательно должен быть «главный» репозиторий.
Грег Хьюгилл

1
@ Том Хэмминг: придерживаться SVN, потому что вы приобрели и установили сервер SVN, действительно является ошибочной ошибкой. Git и Mercurial бесплатны, а стоимость VisualSVN уже оплачена, так что посмотрите на ваши варианты, так как в будущем у каждого будет одинаковая (нулевая) стоимость начальной установки.
Cercerilla

7

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


5

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

Всегда задумывался "почему была добавлена ​​эта строка кода"? Найдите коммит, который его представил, и посмотрите его комментарий. Если вы делаете коммит только при запуске, комментарии не будут достаточно конкретными, чтобы быть полезными для вас.

Я также хотел бы предложить вам использовать более мощный инструмент, чем SVN. Вы можете увидеть хорошее представление о возможностях на http://hginit.com/ Джоэля Споелски.

Он использует ртуть, и в наши дни есть несколько соперников. Git считается очень мощным, и https://github.com/ имеет очень полезные инструменты и предоставляет бесплатные стартовые аккаунты, так что вы можете попробовать его по-настоящему.


3

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


2

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


SVN тоже может это сделать.
Фил Лелло

2

Джо - хакер, а не разработчик. Он звучит как очень хороший хакер, но он ошибается в том, как использовать контроль версий. Так что с этим делать?

Мне кажется, что ваша организация инвестирует в SVN, и вам будет сложно ограничить карьеру, бросив вызов Джо и лишив вас долларовых инвестиций в сервер SVN. Настройте репозиторий GIT и используйте интерфейс git svn, чтобы работать так, как вы хотите (это все бесплатное программное обеспечение, и на настройку у вас уйдет час или день, все на вашей рабочей станции). Социализируйте ваш рабочий процесс с Джо - он может сохранить свою систему убеждений «незагрязненного репо SVN» и сохранить доверие к дорогому белому слону в углу (и эго).

В скором времени я ожидаю, что Джо рассмотрит, как вы работаете, и начнет делать то же самое. Через год или два SVN-сервер станет Git-репо.


долларовые инвестиции в сервер svn будут не больше долларовых инвестиций в сервер git repo ...
TZHX

2

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


2

Я собираюсь повторить @ Carson63000 здесь и сказать, что я видел такое отношение раньше, и оно в значительной степени вызвано ужасными возможностями ветвления / слияния VCS. Наличие ветки, которая компилирует и проходит тесты, с тегами для каждого выпуска, является отличным подходом, но его не следует придерживаться до такой степени, что никакой другой код не передается. DVCS в целом и git в частности делают ветвление простой и распространенной операцией, что значительно облегчает этот рабочий процесс.


1

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


0

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

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


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

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