Рекомендуемые методы разработки для работы с Siebel CRM?

Question

Вскоре я могу работать с Siebel CRM, и я ищу советы по использованию современных практик разработки и лучших практик предприятия.

В частности, я хотел бы совет по следующим направлениям:

• Как мы должны настроить контроль версий (в частности, с Subversion)? Какая структура должна иметь наш репозиторий? Как мы должны обрабатывать филиалы и теги?
• Как мы можем сделать код отзывы? Как мы можем рассмотреть изменения конфигурации обзора, сделанные через инструменты Siebel, которые не обязательно имеют какой-либо «код»? Мы хотим просмотреть эти изменения для обеспечения качества и передачи знаний, а также соблюдение политики управления изменениями.
• Какое управление изменения хорошо работает с Siebel? Как мы подтверждаем, что только веща, перечисленные в нашем журнале изменений, фактически изменяются, когда мы выполним новое развертывание?
• Как мы можем автоматизировать тестирование нашего приложения? Удачное тестирование даже возможно с Siebel? Я видел еще один вопрос, предлагающий QTP для веб-тестирования, но есть ли другие варианты, которые работают?
• Есть ли другие вещи, которые мы можем сделать для реализации практики непрерывной интеграции с нашими усилиями развития Siebel?
• Какие рекомендации у вас есть для намыкания соглашений и других вещей, которые традиционно подпадают под руководящие принципы «стиля кодирования»?
• Как мы должны отделить роли развития от ролей администратора Siebel? Как должен выглядеть наш цикл сборки/тестирования/развертывания?

Маловероятно, что я смогу получить какие -либо новые дорогие инструменты для этого, но если есть платный инструмент, который обеспечивает действительно отличную рентабельность инвестиций, не стесняйтесь упоминать об этом.

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

Answer 1

Как мы должны настроить контроль версий (в частности, с подрывной деятельностью)?

Используйте руководство, указанное в документации для инструментов Siebel. Но обратите внимание, что Siebel не строится из файлов в SVN, поэтому он будет полезен только в качестве архивного инструмента; Вы не можете управлять своим кодом или построить из SVN.

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

Код разработки Siebel не создан и не управляется в SVN, так что это довольно бесполезно. Просто обратите внимание на дату, когда вы построили свой SRF и экспортировали репо и сопоставьте с тегом или ветвью в SVN.

Как мы можем сделать обзоры кода? Как мы можем оценить изменения конфигурации, сделанные с помощью инструментов Siebel, которые не обязательно имеют «код»? Мы хотим рассмотреть эти изменения для обеспечения качества и передачи знаний, а также соблюдение политики управления изменениями.

Используйте инструменты Siebel, чтобы сделать это. Он имеет встроенный «Проверка» инструмент для очевидных ошибок (все разработки должны использоваться до тех пор, прежде чем они проверяют) и инструмент Diff (вам нужно будет проверить на более старую версию того же объекта, - которую вы могли бы перетащить из SVN Если хочешь). Я обычно автоматизурую инструмент проверки один раз в день и просмотрите журналы вывода и автоматизируйте сборку с сервера Siebel 5 раз в день и ищу ошибки во время компиляции. Дифференциры через SVN и стандартный инструмент Shiff может быть возможен, но объекты Siebel хранятся в виде XML-подобных файлам в SVN, и поэтому иногда трудно прочитать.

Какое управление изменениями хорошо работает с Siebel? Как мы подтвердим, что только вещи, перечисленные в нашем журнале изменений, фактически изменяются, когда мы делаем новое развертывание?

?

Как мы можем автоматизировать тестирование нашего приложения? Возможна ли модульные тестирование с Siebel? Я видел еще один вопрос, предлагающий QTP для веб -тестирования, но есть ли другие варианты, которые работают?

QTP - это стандартный путь - проверить веб -сайт Oracle для других поставщиков, которые они могут порекомендовать. Вы также можете попробовать Сикули.

Есть ли другие вещи, которые мы можем сделать, чтобы внедрить практику непрерывной интеграции с нашими усилиями по разработке Siebel?

Не совсем.

Какие рекомендации у вас есть для именования соглашений и других вещей, которые традиционно подпадают в руководящие принципы «Стиль кодирования»?

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

Как мы должны отделить роли развития от ролей администратора Siebel?

Не уверен, что вы имеете в виду.

Как должен выглядеть наш цикл сборки/тестирования/развертывания?

Создайте новый SRF и экспортируйте новое репо из Dev раз за ночь. После того, как все работы разработчиков были зарегистрированы и модульные тесты выполняются, возьмите следующий SRF и репо и подтолкните в тестовую среду. На данный момент в обычной разработке программного обеспечения вы разведите свой SVN и продолжаете развиваться на багажнике, но Siebel отличается, потому что вы не можете построить из SVN, и вы не можете легко восстановить множество файлов из SVN в свою среду сборки, так что вы » Лучше всего делать горячие исправления для тестирования либо в DEV (и приостановите развитие Mainline DEV до тех пор, пока это не будет сделано), либо в тестовой среде, и сделайте уродливые обратные сообщения в среду разработки (это то, что большинство людей делают на самом деле). Создайте новый SRF и экспортируйте новое репо из теста один раз за ночь, и, как только это будет хорошо, сделайте копию для вашего производственного релиза. Постарайтесь придерживаться циклов не более 4 недель (1 неделя для Desing/Prototyping. 1 неделя для Dev, 1 неделя для тестирования, 1 неделя для исправлений ошибок и развертывания) - дольше, и накладные расходы на планирование тоже станут здорово.

Намекает на более легкую жизнь: избегайте засипки, кроме как в бизнес -услугах (в противном случае это становится неуправляемым); Используйте все встроенные инструменты Siebel вместо собственного Rolling Your; Старайтесь избегать каких-либо функциональности сброса (это всегда кажется хорошей идеей, но всегда разрушает производительность); Держите количество экранов и видов на абсолютный минимум; Не строите виды, когда вам следует создавать отчеты; Всегда следите за тем, чтобы таблицы EIM совпадали с схемами, которые вы делаете - даже если вы не используете EIM прямо сейчас; Попробуйте создать объекты интеграции в соответствии с вашей логической схемой - они всегда полезны (для веб -сервисов, XML Publishing) и адской работы для строительства после факта; предпочитают политики рабочего процесса в течение событий времени выполнения; Не добавляйте новые спецификации Sort или поиска без индексов - когда -либо когда -либо; Не делайте ссылки на таблицу LOV; Всегда патч; Если продавец не говорит, что вы можете что -то сделать, никогда не делайте этого.

Answer 2

Мы создали полный инструмент для непрерывной интеграции для наших систем Siebel, состоящих из подрывной деятельности, Гудзона, Jira, Siebel ADM и некоторых самозаписных вещей, интегрирующих все.

Это многое, хотя Siebel «исходный код» не так подходит для стандартных подходов CI, как, скажем, некоторый проект на основе Java.

И, да, можно поместить ваши файлы - включая SIF - в ваш репозиторий подрывной деятельности и использовать это как источник для ваших развертываний.

Я планирую вести блог об этом в http://siebel-ci.blogspot.de/ - быть в курсе.

Answer 3

SVN / CVS не подходит для Siebel, несколько причин
а) Объекты Siebel являются объектами DB и магазин SVN / CVS ETC SIF, эквивалентны изменениям.
Эти изменения невозможно запросить, за исключением некоторых основных запросов.
б) Интеграция между инструментами Siebel и SVN является слабо связанной интеграцией.
Идеальная интеграция должна быть с репозиторием Siebel и Invidual Tools.

Взгляните на наш объект инструмента, он рассматривает многие недостатки управления версиями на основе файлов.
http://www.enterprisebeacon.com/siebel_version_control_tool.html
Object Hive был с нуля специально для контроля версий Siebel, некоторые из его функций:
1) Репозиторий на основе объектов, аналогичный репозиторию Siebel, в котором хранится вся история версий.
Это очень легко запрашивать изменения и провести обзоры кода на основе изменений
2) GUI на основе браузера, который аналогичен инструменту Siebel для запроса истории версии (не расчесывает файлы SIF для изменений).
3) Бесплатная интеграция - непосредственно интегрируется с репозиторием Siebel.
Нет грязной установки для Invidual Developer. 4) Мощная отчетность (реальное время и партия), чтобы легко идентифицировать изменения в течение любого периода времени.
5) Сертифицировано Oracle Exa.