Рекомендуемые практики разработки для работы с Siebel CRM?
Возможно, я скоро буду работать с Siebel CRM, и я ищу советы по использованию современных методов разработки и лучших корпоративных практик.
В частности, я хотел бы получить совет по следующим направлениям:
- Как мы должны настроить контроль версий (особенно с Subversion)? Какую структуру должен иметь наш репозиторий? Как мы должны обращаться с ветками и тегами?
- Как мы можем сделать обзоры кода? Как мы можем просмотреть изменения конфигурации, сделанные с помощью Siebel Tools, которые не обязательно содержат какой-либо "код"? Мы хотим проверить эти изменения на предмет обеспечения качества и передачи знаний, а также соответствия политикам управления изменениями.
- Какой тип управления изменениями хорошо работает с Siebel? Как мы можем убедиться, что только вещи, перечисленные в нашем журнале изменений, действительно изменены, когда мы делаем новое развертывание?
- Как мы можем автоматизировать тестирование нашего приложения? Возможно ли модульное тестирование с Siebel? Я видел другой вопрос, предлагающий QTP для веб-тестирования, но есть ли другие варианты, которые работают?
- Есть ли что-то еще, что мы можем сделать, чтобы внедрить методы непрерывной интеграции с нашими усилиями по разработке Siebel?
- Какие рекомендации вы предлагаете для соглашений об именах и других вещей, которые традиционно подпадают под рекомендации "стиля кодирования"?
- Как мы должны отделить роли разработчиков от ролей Siebel Administrator? Как должен выглядеть наш цикл сборки / тестирования / развертывания?
Маловероятно, что я смогу получить какие-либо новые дорогие инструменты для этого, но если есть платный инструмент, который обеспечивает действительно высокую рентабельность инвестиций, не стесняйтесь упоминать об этом.
Если у вас есть другие рекомендации в этом направлении, но они не были конкретно указаны в одном из моих вопросов, не стесняйтесь добавить их.
3 ответа
Как мы должны настроить контроль версий (особенно с Subversion)?
используйте указания, приведенные в документации для Siebel Tools. Но учтите, что Siebel не собирает файлы из SVN, поэтому он будет полезен только как инструмент архивирования; Вы не можете управлять своим кодом или строить из SVN.
Какую структуру должен иметь наш репозиторий? Как мы должны обращаться с ветками и тегами?
Код разработки Siebel не создается и не управляется в SVN, так что это довольно бесполезная вещь. Просто запишите дату, когда вы создали свой SRF и экспортировали репо, и сопоставьте его с тегом или веткой в SVN.
Как мы можем сделать обзоры кода? Как мы можем просмотреть изменения конфигурации, сделанные с помощью Siebel Tools, которые не обязательно содержат какой-либо "код"? Мы хотим проверить эти изменения на предмет обеспечения качества и передачи знаний, а также соответствия политикам управления изменениями.
Используйте Siebel Tools для этого. Он имеет встроенный инструмент "проверки" на наличие очевидных ошибок (все разработчики должны использовать его до регистрации) и инструмент сравнения (вам нужно будет проверить более старую версию того же объекта - которую вы можете перетащить из SVN). если ты хочешь). Обычно я автоматизирую средство проверки один раз в день и просматриваю выходные журналы, а также автоматизирую сборку с сервера Siebel 5 раз в день и ищу ошибки во время компиляции. Различия с использованием SVN и стандартного средства сравнения могут быть возможны, но объекты Siebel хранятся в формате XML-подобных файлов в SVN, поэтому иногда их трудно прочитать.
Какой тип управления изменениями хорошо работает с Siebel? Как мы можем убедиться, что только вещи, перечисленные в нашем журнале изменений, действительно изменены, когда мы делаем новое развертывание?
?
Как мы можем автоматизировать тестирование нашего приложения? Возможно ли модульное тестирование с Siebel? Я видел другой вопрос, предлагающий QTP для веб-тестирования, но есть ли другие варианты, которые работают?
QTP является стандартным способом - проверьте на веб-сайте Oracle других поставщиков, которых они могут порекомендовать. Вы также можете попробовать Sikuli.
Есть ли что-то еще, что мы можем сделать, чтобы внедрить методы непрерывной интеграции с нашими усилиями по разработке Siebel?
На самом деле, нет.
Какие рекомендации вы предлагаете для соглашений об именах и других вещей, которые традиционно подпадают под рекомендации "стиля кодирования"?
Ознакомьтесь с соответствующим разделом Siebel Bookshelf, чтобы ознакомиться с текущими правилами именования, и всегда используйте их.
Как мы должны отделить роли разработчиков от ролей 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; всегда патч; если продавец не говорит, что вы можете что-то сделать, никогда не делайте этого.
Мы установили полный набор инструментов для непрерывной интеграции для наших систем Siebel, состоящий из Subversion, Hudson, Jira, Siebel ADM и некоторых самостоятельных материалов, объединяющих все.
Это очень здорово, хотя "исходный код" Siebel не так подходит для стандартных подходов CI, как, скажем, в некоторых проектах на основе Java.
И, ДА, вы можете поместить ваши файлы - включая SIF - в ваш репозиторий Subversion и использовать их как источник для ваших развертываний.
Я планирую в блоге об этом в http://siebel-ci.blogspot.de/ - следите за обновлениями.
SVN/CVS не подходят для Siebel, по нескольким причинам
a) Объекты Siebel являются объектами db, а SVN/CVS и т. д. хранят sif-эквивалент изменений.
Эти изменения невозможно запросить, за исключением некоторых основных запросов.
б) Интеграция между инструментами Siebel и SVN является слабосвязанной интеграцией.
Идеальная интеграция должна быть с репозиторием Siebel и отдельными инструментами.
Взгляните на наш инструмент Object Hive, который устраняет многие недостатки управления версиями на основе файлов.
http://www.enterprisebeacon.com/siebel_version_control_tool.html
Object Hive был разработан с нуля специально для контроля версий Siebel, некоторые его особенности:
1) Объектно-ориентированный репозиторий, аналогичный репозиторию Siebel, в котором хранится вся история версий.
Это позволяет очень легко запрашивать изменения и проводить проверки кода на основе изменений
2) Графический интерфейс на основе браузера, аналогичный инструментам Siebel для запроса истории версий (не нужно расчесывать sif-файлы на предмет изменений).
3) Полная интеграция - напрямую интегрируется с репозиторием Siebel.
Нет грязной установки для стороннего разработчика.
4) Мощные отчеты (в режиме реального времени и в пакетном режиме), чтобы легко идентифицировать изменения за любой период времени.
5) Сертификат Oracle Exa-ready.