Какую стратегию резервного копирования вы используете для своего кода?

Question

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

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

Какие стратегии резервного копирования, кроме контроля исходного кода, вы используете для обеспечения безопасности своего кода?

Подобный вопрос можно найти на https://stackoverflow.com/questions/38388/organization-wide-backup-strategy,, но мне больше интересно услышать личные стратегии других, если вам случится работать в организации, у которой нет общей стратегии. Я изложу свою стратегию в ответ.

Answer 1

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

Answer 2

Version Control (SVN) мне более чем достаточно. Тем не менее, есть несколько правил:

• Я совершаю как можно чаще (4-6 часов работы без обязательств уже начинают создавать это покалывание, что-то идет не так).
• SVN-структуры решений всегда атомарны. Вам просто нужен новый CheckOut, чтобы иметь возможность запускать скрипт интеграции "rebuild-copy-package" в любом решении (для запуска тестов перед этим может потребоваться указать параметры подключения к БД).
• Сервер SVN надежен и регулярно выполняет резервное копирование.
• Изменения распространяются между различными решениями, составляющими приложение (т. Е. Из общедоступной библиотеки с открытым исходным кодом во внутренний код, который ее использует), только через коммиты (сервер интеграции забирает это и создает пакеты, которые могут использоваться в решениях -stream). * * +1010
• Проекты песочницы (прототипы) всегда хранятся в папке Prototypes SVN (одноуровневый элемент магистрали или тегов) с именем «YYYY-MM-DD PrototypeName»

Answer 3

НЕ ИСПОЛЬЗУЙТЕ двунаправленные инструменты синхронизации для резервного копирования

... ну, по крайней мере, не автоматически

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

Answer 4

Я использую продукт (который я написал, это мой микро-isv), который называется Transactor Code Agent. Это инструмент резервного копирования, разработанный специально для программистов.

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

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

1. Source Control предназначен для управления изменениями, чтобы помочь вашей программе перейти из одного согласованного состояния в другое
2. Вам не нужно беспокоиться о поддержке частной ветки
3. Вам не нужно прерывать свою работу, чтобы выполнять проверки исключительно в целях резервного копирования. Вы можете просто сосредоточиться на написании кода и проверять свои вещи, когда это будет сделано.

Вы можете скачать демо-версию здесь:

http://www.transactor.com/download

Answer 5

Мы также проверяем все (регистрируемся рано и часто) и резервируем весь репозиторий (CVS) с помощью tar и переносим его на наш сервер резервного копирования.

Answer 6

Код, который не зарегистрирован (и, следовательно, не скопирован) в вашу VCS, не существует Это не более реально, чем код, который вы просто имеете в своей голове. Это действительно так просто.

Answer 7

Я работаю над продуктом под названием «Агент кода Transactor», который предназначен для выполнения именно того, о чем вы просите.

Обеспечивает локальное резервное копирование и контроль версий ваших исходных файлов.

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

Бета-версия должна выйти в январе.

Вы можете увидеть наш "веб-сайт" (это немного грубо) на

www.transactor.com

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

Обновление:

Вот немного больше информации, основанной на некоторых отзывах, которые я получил в комментариях:

1) Есть ли у меня что-то снова с контролем исходного кода?

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

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

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

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

Answer 8

Когда вы пишете что-то, что (пока) не принадлежит основной сборке, создайте ветку. Когда он должен войти в основную сборку, объедините с ним свою ветку.

Распределенные VCS также упрощают локальные ветки, центральный репозиторий никогда не узнает, что они существуют.

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

Answer 9

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

Answer 10

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