Как настроить управление версиями (особенно с Subversion)?
используйте указания, приведенные в документации для Siebel Tools.Но учтите, что Siebel не собирает файлы из SVN, поэтому он будет полезен только как инструмент архивирования;Вы не можете управлять своим кодом или сборкой из SVN.
Какую структуру должен иметь наш репозиторий?Как мы должны обрабатывать ветки и теги?
Код разработки Siebel не собирается и не управляется в SVN, так что это довольно бесполезная вещь.Просто запишите дату, когда вы создали свой SRF и экспортировали репо, и сопоставьте его с тегом или веткой в SVN.
Как мы можем выполнять проверки кода?Как мы можем просмотреть изменения конфигурации, сделанные с помощью Siebel Tools, которые не обязательно содержат какой-либо «код»?Мы хотим проверить эти изменения на предмет обеспечения качества и передачи знаний, а также соответствия политикам управления изменениями.
Используйте для этого Siebel Tools.Он имеет встроенный инструмент «проверки» на наличие очевидных ошибок (все разработчики должны использовать его до регистрации) и инструмент сравнения (вам нужно будет проверить более старую версию того же объекта - которую вы можете перетащить из SVN).если ты хочешь).Обычно я автоматизирую инструмент проверки один раз в день и просматриваю выходные журналы, а также автоматизирую сборку с сервера Siebel 5 раз в день и ищу ошибки во время компиляции.Различия с использованием SVN и стандартного средства сравнения могут быть возможны, но объекты Siebel хранятся в формате SVN в виде XML-файлов, поэтому их трудно читать.
Какого рода управление изменениямихорошо работает с Siebel?Как мы можем убедиться, что только те вещи, которые перечислены в нашем журнале изменений, действительно изменены при новом развертывании?
?
Как мы можемавтоматизировать тестирование нашего приложения?Возможно ли модульное тестирование с Siebel?Я видел другой вопрос, предлагающий QTP для веб-тестирования, но есть ли другие варианты, которые работают?
QTP является стандартным способом - проверьте на веб-сайте Oracle других поставщиков, что они могутрекомендую.Вы также можете попробовать Sikuli.
Есть ли что-то еще, что мы можем сделать, чтобы реализовать методы непрерывной интеграции с нашими усилиями по разработке Siebel?
Не совсем.
Какие рекомендации вы предлагаете для соглашений об именах и других вещей, которые традиционно подпадают под рекомендации "стиля кодирования"?
Оформить заказраздел Siebel Книжная полка, где приведены текущие рекомендации по именованию, и используйте их всегда.
Как следует отделить роли разработки от ролей Siebel Administrator?
Не уверен, что вы имеете в виду.
Как должен выглядеть наш цикл сборки / тестирования / развертывания?
Создайте новый SRF и экспортируйте новый репо из Dev раз в ночь.После того, как вся работа разработчика была проверена и модульные тесты выполнены, возьмите следующий SRF и Repo и отправьте в среду тестирования.На этом этапе обычной разработки программного обеспечения вы бы разветвляли свой SVN и продолжали разрабатывать в магистрали, но Siebel отличается тем, что вы не можете собрать из SVN, и вы не можете легко восстановить большое количество файлов из SVN в вашу среду сборки, поэтому вы 'Лучше всего делать оперативные исправления для тестирования либо в dev (и приостанавливать разработку mainline dev до тех пор, пока это не будет сделано), либо в тестовой среде, и делать некрасивые обратные переносы в среду разработки (это то, что фактически делает большинство людей).Создайте новый SRF и экспортируйте новый репо из Test раз в ночь, и, если это хорошо, сделайте снимок для вашей рабочей версии.Старайтесь придерживаться циклов не более 4 недель (1 неделя для разработки / создания прототипа. 1 неделя для разработчика, 1 неделя для тестирования, 1 неделя для исправления ошибок и развертывания) - дольше, чем это, и накладные расходы на планирование станут слишком большимиотлично.
Подсказки для облегчения жизни: избегайте eScript, кроме как в Business Services (в противном случае он становится неуправляемым);используйте все встроенные инструменты Siebel вместо своих собственных;старайтесь избегать любых функций свертывания (это всегда кажется хорошей идеей, но всегда снижает производительность);сохранить минимальное количество экранов и просмотров;не создавайте представления, когда вместо этого вы должны создавать отчеты;всегда проверяйте соответствие таблиц EIM и расширений схемы, которые вы делаете, даже если вы не используете EIM прямо сейчас;попытайтесь построить объекты интеграции в соответствии с вашей логической схемой - они всегда полезны (для веб-сервисов, публикации XML) и представляют собой чертовски сложную работу по факту;предпочитаю политики рабочего процесса событиям во время выполнения;не добавляйте новые сортировки или спецификации поиска без индексов - никогда когда-либо;не делайте ссылки-ссылки на таблицу LOV;всегда патч;если продавец не говорит, что вы можете что-то сделать, никогда не делайте этого.