Год назад я закончил колледж по компьютерным наукам и сейчас работаю в небольшой компании, занимающейся веб-разработкой (я и еще один разработчик, а также менеджеры, служба поддержки клиентов и тестировщик). До того, как я начал, не было системы контроля версий. Сейчас мы постепенно начинаем внедрять SVN, но другой (старший) разработчик (далее именуемый Джо) настаивает на том, что единственный код, который должен быть зафиксирован в нашем SVN-репозитории, - это тот, который был протестирован и одобрен как готовый к работе. Это означает, что в более крупных проектах коммиты могут быть неделями неделями или дольше.
Это нормальная практика? Мне кажется, что мы теряем много преимуществ контроля версий, в том числе:
- Детальное отслеживание хода проекта
- Отслеживание проблем по мере их появления и решения
- Легко откат ошибок
- Простое резервное копирование кода, поэтому мы не потеряем много, если рабочая станция выйдет из строя
- Проще точно определить, какой код выполняется на каких рабочих сайтах, если мы помечаем исправления в исполняемые файлы, как описано здесь
- Простое сотрудничество (хотя мы не делаем никакой командной работы; это все сольные проекты)
- И т.п.
РЕДАКТИРОВАТЬ: Я должен подчеркнуть, что исторически, в этой компании не было никакой настоящей командной работы; всего два разработчика работают над отдельными проектами. Кроме того, многие проекты небольшие, поэтому они могут быть завершены в течение нескольких недель. И компания была в бизнесе более десяти лет и прекрасно обходилась без контроля источников. Проекты обычно завершаются в установленные сроки.
источник
Ответы:
Если проекты завершены в установленные сроки, можно ли предположить, что клиенты являются счастливыми клиентами? :)
Похоже, что компания начинает брать на себя новые типы проектов и переживает некоторые проблемы роста или некоторые "переменные боли". Много предположения происходит здесь ... Пожалуйста, потерпите меня!
Если вы уверены, что организация и контроль кода могут помочь вам и вашей команде внутренне, тогда SVN следует рассмотреть, ИМХО. Вы получаете бонусные баллы, если этот маршрут действительно работает, и компания способна производить продукцию более высокого качества, тем самым делая счастливых клиентов!
Будьте осторожны, если кажется, что борьба с руководством создаст напряженную рабочую среду. Дело в том, что владельцы сделали компанию. И не только это, они сделали успешную компанию. Вряд ли они выиграют джекпот, потому что они хороши в азартных играх.
Будьте уважительны, и вас могут услышать.
Надеюсь, это приведет к созданию более эффективной и счастливой команды. По моему опыту, это трудно получить с расстроенным управлением.
источник
Джо совершенно неправ. Теперь вы можете сделать аргумент, что у вас есть одна «чистая» ветвь, которая представляет проверенный, готовый к работе код. Но откровенное саморазрушение не означает использование контроля исходного кода, пока все не будет готово. Вроде как пытаться приготовить мартини без джина.
источник
«Старший» на самом деле очень неквалифицированный. Любой код, который может быть скомпилирован (и проходит тесты, если они у вас есть), должен быть передан в систему контроля версий. Контроль исходного кода является центральным активом для совместного использования кода и наращивания ПО.
Хорошим моментом является разделение производственного кода (последняя стабильная версия), но для таких случаев системы контроля версий содержат такие функции, как теги / метки и ветви.
Наша команда воспринимает очень подозрительно, если кто-то ничего не совершает в течение двух-трех дней. Это означает, что у него есть некоторые проблемы и, возможно, ему нужна помощь. Еще одна точка контроля исходного кода заключается в том, что он обычно регулярно резервируется, что не относится к машинам разработки. Если ваш диск сломается, вы потеряете работу на несколько недель.
источник
Оставляя в стороне вопрос о том, прав Джо или нет (кстати, он неправ), мне кажется, что компромисс может быть достигнут, если вы используете распределенную систему контроля версий, такую как Git или Mercurial .
Таким образом, вы и другой разработчик будете работать с вашим локальным репозиторием, передавая ваши изменения в систему управления версиями рано и часто, но не отправляйте свои изменения в «производственный» репозиторий, пока они не будут «протестированы и утверждены как готовые к работе». У вас была бы полная история каждого, над чем вы работали в течение нескольких недель, и у Джо был бы нетронутый репозиторий, в котором была только история изменений, которые были благословлены как готовые к производству.
источник
git svnдля взаимодействия. Вам не нужно ничего покупать и вам не нужно никого убеждать; им даже не нужно знать.git pushвносить изменения на другой компьютер (в качестве резервной копии). Это не обязательно должен быть «главный» репозиторий.Это не имеет смысла, по тем самым причинам, которые вы перечислили. Это похоже на использование контроля версий без преимуществ использования контроля версий.
источник
Я полагаю, что Джо не понимает, что системы управления исходным кодом - это не прославленные резервные копии выпусков исходного кода, а полезный инструмент для программистов, который рассказывает о небольших шагах прогресса и зрелости кода для себя и своих коллег. Возможно, Джо не привык работать в командах с кодом других людей?
Всегда задумывался "почему была добавлена эта строка кода"? Найдите коммит, который его представил, и посмотрите его комментарий. Если вы делаете коммит только при запуске, комментарии не будут достаточно конкретными, чтобы быть полезными для вас.
Я также хотел бы предложить вам использовать более мощный инструмент, чем SVN. Вы можете увидеть хорошее представление о возможностях на http://hginit.com/ Джоэля Споелски.
Он использует ртуть, и в наши дни есть несколько соперников. Git считается очень мощным, и https://github.com/ имеет очень полезные инструменты и предоставляет бесплатные стартовые аккаунты, так что вы можете попробовать его по-настоящему.
источник
Джо, похоже, не знает о SVN, попробуйте узнать о ветвях, тегах и магистралях ... Теги соответствуют тому, что хочет Джо. Некоторое чтение лучших рекомендаций SVN не повредит
источник
Никогда не использовал SVN, поэтому я не знаю, какие процедуры для этого будут. Мы используем ClearCase, и практика здесь заключается в том, чтобы у каждого разработчика была своя собственная ветвь разработки, затем ветвь интеграции, с которой мы объединяемся, когда мы готовы начать тестирование, и одна или несколько веток релиза для интегрированного и протестированного кода. ,
источник
Джо - хакер, а не разработчик. Он звучит как очень хороший хакер, но он ошибается в том, как использовать контроль версий. Так что с этим делать?
Мне кажется, что ваша организация инвестирует в SVN, и вам будет сложно ограничить карьеру, бросив вызов Джо и лишив вас долларовых инвестиций в сервер SVN. Настройте репозиторий GIT и используйте интерфейс git svn, чтобы работать так, как вы хотите (это все бесплатное программное обеспечение, и на настройку у вас уйдет час или день, все на вашей рабочей станции). Социализируйте ваш рабочий процесс с Джо - он может сохранить свою систему убеждений «незагрязненного репо SVN» и сохранить доверие к дорогому белому слону в углу (и эго).
В скором времени я ожидаю, что Джо рассмотрит, как вы работаете, и начнет делать то же самое. Через год или два SVN-сервер станет Git-репо.
источник
Вы можете попытаться убедить Джо с аргументами выше. Если это не удастся, используйте SVN локально для своей собственной работы по разработке и надеюсь, что Джо когда-нибудь его подберет. Если вы не можете убедить их аргументами, сделайте то, в чем вы убеждены, и покажите им, что это работает. Вид распределенного подхода, но с существующим инструментарием.
источник
Я собираюсь повторить @ Carson63000 здесь и сказать, что я видел такое отношение раньше, и оно в значительной степени вызвано ужасными возможностями ветвления / слияния VCS. Наличие ветки, которая компилирует и проходит тесты, с тегами для каждого выпуска, является отличным подходом, но его не следует придерживаться до такой степени, что никакой другой код не передается. DVCS в целом и git в частности делают ветвление простой и распространенной операцией, что значительно облегчает этот рабочий процесс.
источник
Причины, по которым системы контроля версий поддерживают теги, заключаются в том, что вы можете пометить сертифицированный код и при этом выполнять свою повседневную работу. Всякий раз, когда у вас есть код качества производства, вы фиксируете его, теряете тег и все готово. Вы знаете точный момент времени, когда вам нужно вернуться, чтобы получить то, что имеет клиент. И вы всегда можете проверить и сравнить разные версии вашего кода. Таким образом, вы можете быть довольны тем, что у вас есть в базе данных управления версиями. Это работает для компании, в которой я работаю, в которой 100 разработчиков, все работают над одним проектом. Это, безусловно, сработает и для вас.
источник
Обычно в системах контроля версий хранятся вещи, готовые к отправке в производство. Вот как это делалось исторически на протяжении десятилетий, с тех давних времен, когда дисковое хранилище стоило сотни долларов за мегабайт, а хранить все было слишком дорого.
Это больше не считается лучшим способом сделать что-то, но я могу полностью понять, почему люди все еще делают это, так как многие старые системы контроля версий все еще используются, которые затрудняют, если не делает невозможным что-либо еще, и сохраняют знание того, что вы делаете. каждый выпуск (или, скорее, невозможно узнать, что такое любой выпуск, не проверив теги на каждом файле, если вам нужно вернуться назад. Я видел более одного хранилища, где единственный способ вернуть старый релиз должен был получить из репозитория zip-файл с исходным кодом и двоичными файлами для этого выпуска).
источник