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

Question

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

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

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

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

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

P.S. я видел этот Публикация, но она не полностью отвечает на мой вопрос.

Answer 1

Мы используем Инструменты разработчика Oracle для Visual Studio.NET...подключается прямо к TFS

Answer 2

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

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

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

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

Answer 3

Видеть мой ответ о Инструменты для работы с хранимыми процедурами в Oracle в команде (который я только что пометил).

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

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

Answer 4

Чтобы избежать одновременной работы двух разработчиков над одним пакетом:

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

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

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Насколько мне известно, инструменты разработчика Oracle для Visual Studio.Net не имеют реальной интеграции системы управления версиями с TFS или чем-либо еще.

Вы можете рассмотреть Расширения Toad для Visual Studio хотя это недешево, я думаю, может быть, 4 тысячи долларов.

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