Реализация контроля версий

Question

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

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

Answer 1

Вы должны заставить его думать, что это его идея.

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

Answer 2

Установите SVN и скажите противнику, что "все это делают" :) А если серьезно, контроль над исходным кодом ОБЯЗАН даже для одного разработчика, не говоря уже о трех.

Что касается сервера БД - вы можете использовать один сервер разработки (это может быть обычный компьютер). Конечно, нет проблем, если вы используете каждую локальную копию, но у вас должны быть сильные инструменты генерации / синхронизации схемы базы данных.

Answer 3

Очевидно, что существует множество способов справиться с людьми (и по большей части у вас есть "люди").

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

1. Дополнительная работа по совершению
2. Не всегда работает рядом с интернетом
3. не вижу в нем лишних значений

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

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

Если он не всегда работает рядом с доступом в Интернет, рассмотрите такую ​​систему, как GIT. Преимущество GIT (по сравнению с чем-то вроде SVN) состоит в том, что он использует модель выталкивания вместо толчка. В результате вы извлекаете обновления от других пользователей GIT, а не нажимаете коммиты. Если вы работаете в самолете и не имеете доступа к Интернету, это полезная функция.

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

Хороший способ продемонстрировать важность хранилища - это Daily Build. Ежедневная сборка означает, что вы можете легко интегрировать функции и быстрее находить ошибки. Создание репозитория с ежедневной сборкой значительно улучшит ваши условия работы и, вероятно, произведет хорошее впечатление.

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

Answer 4

Похоже, вам нужно убедить его, что это

1. Необходимо решить проблему,
2. соответствующее решение (делает именно то, что вам нужно) и
3. прост в использовании.

Похоже, у вас есть информация, чтобы продемонстрировать # 1: в последний раз код «сам по себе» изменялся на сервере, и вы потеряли чью-то работу или плохо смешали результаты. Бэм, вот твоя "проблема". # 3 - следующий более сложный: вам нужно выбрать SCM с хорошим набором инструментов и сделать демонстрацию. Линейка продуктов TortoiseX (TortoiseHg, TortoiseSVN) отлично подходит для этого, потому что они делают ее не страшной.

Пункт 2 - самое трудное: продемонстрировать, что это подходящее решение. Возможно, чтобы убедить его в этом, вы можете обратиться к анекдотам других программистов или, взглянув на Github, где вы можете оглянуться на предыдущие версии продукта. Я хватаюсь за соломинку здесь, потому что чувствую, что его аргумент будет звучать так: «Ах, а это когда огромная головная боль, это когда вещи ломаются. Это не стоит того».

Answer 5

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

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

При удаче медленно со временем он начнет видеть преимущества ( его: о нет - все просто сломалось! ты: Не волнуйся, я просто посмотрю и посмотрим, что изменилось со времени последней рабочей копии ...)

Answer 6

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

Answer 7

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