Siebel Workspaces: Best Practices

 

 

In the Cloud Customer Connect Webinar “Workspaces – Behind the Scenes”, I examined the technical aspects of how Workspaces operate behind the scenes in Siebel. In this blog, I will discuss Workspaces in general and some best practices for the developers to manage them effectively.

 

Here is a link to the Webinar:

https://community.oracle.com/customerconnect/events/605639-cx-siebel-workspaces-behind-the-scenes

Siebel Workspaces

In Siebel, a Workspace acts as a sandbox where developers can make and test changes to configurations without impacting other Workspaces. Developers are free to experiment while ensuring that existing configurations remain untouched and protected. Within a Developer Workspace, you can’t delete or overwrite existing configurations, thus ensuring a secure testing space.

Workspace Types

  • Developer Workspace: Where developers can modify or add configurations.
  • Integration Workspace: Where multiple Developer Workspaces are combined together for integrated testing.

Best Practices

MAIN/Latest = Production

Your production Runtime Repository should always match what is in your MAIN/Latest Workspace version in your Design Repository. This indicates that nothing should be delivered to MAIN until it is ready for Production. You would certainly not want half-tested configurations to make it into Production, so MAIN/Latest should always be production-ready.

Testing always completed before delivering to MAIN

There will always be multiple rounds of testing for each configuration change along the way. Typically, you do the unit testing in your Developer Workspace. When you are confident, you deliver that workspace to its parent. The delivered configuration will then be stored along with other configurations in this Workspace. This incurs another round of testing as all these configurations are tested together. This is typically done in an Integration Workspace, but it can also be done in a Developer Workspace if needed. Similarly, testing progresses up the chain as additional development branches are delivered. At the end, you may do a pre-production delivery to test everything together in an environment that closely mimics production. Note that MAIN can’t be used for testing, but only for housing the final, tested release that is production ready.

Developer Workspaces directly under MAIN?

Sometimes, you may encounter a production problem that needs a quick fix, it can be accomplished using a Developer Workspace directly under MAIN. This can also go under pre-production but may not in case of an extreme emergency. The only testing that can be done is to the Developer Workspace and this must go to production now. If you deliver something to MAIN that hasn’t followed the proper testing sequence, the untested configuration will also be migrated to production when you deliver the hot fix to MAIN and then move MAIN to production. Hence, you have to keep MAIN production ready.

However, all these Developer Workspaces can stack up under MAIN making the developer’s experience annoying as the increasing number of Workspaces pushes other Workspaces down the tree. In the Siebel Monthly Update 24.7, we have introduced the ability to delete any delivered Developer Workspace so you can avoid this.

Note: Flattening your Workspaces is not recommended for cleanup. This has very severe impact on undelivered configurations and Workspace delivery history. Rather, archive Workspaces and manually delete those Workspaces that are no longer needed for any reason.

Automated Testing

As a developer, when you test your configuration, you can set up automated tests because no one understands better what the configuration does than you. Using the Siebel Test automation or a suite of REST calls can enhance the overall test suite, allowing comprehensive testing when all components are integrated in an Integration Workspace.

Planning Feature Delivery

Your features may combine bug fixes and new functionality. So you need enough time to create and test all the configuration. In such case, you create an Integration Workspace that would encapsulate a feature or feature set. Because the Integration Workspace is scheduled for delivery far enough in the future, you have ample time to complete all necessary tasks by its intended delivery date. This also allows other teams to work on features in parallel, enabling continuous delivery by releasing features sequentially.