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

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

Нижняя строка: не изменяйте процедуры непосредственно с ЖАБОЙ. Сохраните источник как файлы, которые Вы будете хранить в управлении исходным кодом, изменить, затем выполняются.

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

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

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

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

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

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

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

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

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

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

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

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

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

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