Как вы работаете с пакетами Oracle в совместной среде с управлением версиями?

Я работаю в среде нескольких разработчиков в Oracle с большим пакетом. У нас есть шаблон продвижения DEV => TST => PRD. В настоящее время все изменения пакета производятся непосредственно в TOAD, а затем компилируются в пакет DEV.

мы сталкиваемся с двумя проблемами:

  1. параллельные изменения необходимо продвигать по разным расписаниям. Например, разработчик A вносит изменения, которые необходимо продвигать завтра, в то время как разработчик B одновременно работает над a изменения, которые не будут продвигаться еще две недели. Когда приходит время продвижения, мы обнаруживаем, что вручную комментируем вещи, которые еще не продвигаются, а затем раскомментируем их позже...фу!!!

  2. Если два разработчика в одно и то же время вносят изменения и один из них компилируется, он стирает изменения другого разработчика. Нет хорошего слияния; вместо этого выигрывает последняя компиляция.

какие стратегии вы бы рекомендуем обойти это? Мы используем TFS для управления версиями, но еще не использовали это с нашими пакетами Oracle.

П. С. я видел этой posting, но это не полностью отвечает на мой вопрос.

9
oracle package version-control

7 ответов

мы используем:Oracle Developer Tools for Visual Studio.NET ... подключается прямо к TFS

2

ключ должен принять практику только развертывания кода из системы управления версиями. Я не знаком с TSF, но он должен реализовать концепции ветвей, тегов и т. д. Вопрос о том, что развертывать, выпадает из построения и выпуска тегов в системе управления версиями.

Дополнительные советы (для Oracle):

  • лучше всего, если вы разделите спецификацию пакета и тело на разные файлы, которые используют согласованный шаблон файла для каждого (например, ".pks "для спецификации пакета, и".ПКБ" для тела пакета). Если вы используете автоматизированный процесс сборки, который может обрабатывать шаблоны файлов, вы можете создать все спецификации, а затем тела. Это также минимизирует недействительность объекта, если вы развертываете только тело пакета.

  • укажите время для настройки процесса автоматической сборки, который управляется из состояния выпуска или сборки системы управления версиями. Если у вас есть даже умеренное количество объектов кода db, он будет платить чтобы иметь возможность встроить код в справочную систему и сравнить его с вашим qa или производственной системой.

4

посмотреть мой ответ: о инструменты для работы с хранимыми процедурами в СУБД Oracle, в команде (который я только что переназначил).

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

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

4

чтобы избежать 2 разработчиков, работающих над одним и тем же пакетом одновременно:

1) Используйте вашу систему управления версиями в качестве источника кода пакета. Чтобы работать над пакетом, разработчик должен сначала проверить пакет из управления версиями; никто другой не может проверить пакет, пока этот разработчик не проверит его обратно.

2) Не работайте непосредственно с кодом пакета в Toad или любой другой IDE. У вас есть без понятия ли код, над которым вы работаете там является правильным или был изменен одним или несколькими другими разработчиками. Работайте над кодом в скрипте, который вы извлекли из системы управления версиями, и запустите его в базу данных для компиляции пакета. Я предпочитаю использовать хороший текстовый редактор (TextPad) и SQL Plus, но вы также можете сделать это в Toad.

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

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

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

мы делаем это с базой данных Dev для каждого потока и метками для разных потоков.

наше лицензирование Oracle дает нам неограниченные экземпляры dev/test, но мы ISV, у вас может быть другой вариант лицензирования

1

вы можете использовать Oracle developer tools для VS или sql developer. SQL developer интегрируется с Subversion и CVS, и вы можете скачать его бесплатно. Смотрите здесь: http://www.oracle.com/technology/products/database/sql_developer/files/what_is_sqldev.html

1

мы используем Toad для Oracle с поставщиком MSSCCI TFS против TFS 2008. Мы используем Пользовательский Инструмент это извлекает проверки базы данных из системы управления версиями и упаковывает их для выпуска.

насколько мне известно Oracle Developer Tools for Visual Studio.Net не имеет реальной интеграции управления версиями с TFS или иным образом.

вы могли бы рассмотреть расширения Toad для Visual Studio хотя это не дешево, возможно, $4k I думать.

другой вариант Пакет Управления Изменениями Oracle но поверьте, что для этого требуется корпоративная версия Oracle, которая намного дороже.

0