Concurrent Development Model for WebCenter Sites

1.0 Introduction


Several times we are asked the question, “I need to develop multiple versions of the Site at the same time. I have completed phase one and version 1.0 of the website is live on delivery. I am working on version 2.0 in the development environment. It will take another 3 weeks to complete version 2.0 and deploy it to delivery. In the meanwhile, I need to start working on version 3.0. How can I do this?”


The answer is very simple. WebCenter Sites development is like any other software development project. A version control system integrated with the development environment is needed to work on multiple versions concurrently. WebCenter Sites Development Tool Kit, CSDT, has a plugin for Eclipse. This allows developers to use Eclipse IDE, and export/import resources from WebCenter Sites to Eclipse workspace. Eclipse can now be integrated with a version control system of your choice.


Let’s first take a look at the development environment for WebCenter Sites for a medium to large project that requires multiple developers.



2. WebCenter Sites – IDE Integration


As a part of its Developers Tools kit (CSDT), WebCenter Sites has an OOTB integration with Eclipse IDE[1]. Once integrated with Eclipse, the developers interact with WebCenter Sites primarily through Eclipse, which provides a rich set of functions for managing WebCenter Sites resources including Templates, CSElements, Site Entry Assets, Element Catalog Entries and Site Catalog Entries.


Eclipse managed resources are stored as files in a file system. This gives developers the option to integrate with a version control system of their choice. If the resources are modified and WebCenter Sites is running, the resources are automatically synchronized, that is, imported into WebCenter Sites, in its native database representation. Manual synchronization can also be performed in both directions.


This is depicted in the following diagram:





Using the Eclipse integration, developers typically perform the following tasks in Eclipse:

* Create, edit, and delete CSElement, Template, and SiteEntry assets

* Develop JSP elements with standard Eclipse features such as tag completion, syntax highlighting, and debugging

* Export and import assets, asset types, flex families, sites, roles, tree tabs, and start menu items

* Preview WebCenter Sites pages within the Eclipse IDE using an embedded preview browser

* View the WebCenter Sites log file in a dynamically refreshing panel

* Integrate with version control systems


3. Integration with Version Control System


CSDT supports integration with a version control system through Eclipse IDE. Eclipse managed WebCenter Sites resources are stored as files in Eclipse workspace called the Main Developer Tools Workspace. Developers can check-in & check-out resources from their workspace to a version control system. From version control system, the resources can be imported in Development Server. The Development Server is used to keep all the files, assets, asset definitions, templates, elements, etc. of the current version. This is shown in the following diagram:





Typically, developers check-out the templates & CSElements they need to work on to their local development system. After they have finished their work, they check-in their changes to version control system. From version control system they are imported in the Development Server. From Development Server the version can be published to Testing/QA or Management Server as required. The following diagram depicts this scenario.



1. The developers check-out the template/CS-Element from Version Control System, and create/modify templates & CS-Elements on their laptop or on the sandbox. The laptop/sandbox has WebCenter Sites along with Eclipse Plug-in.

2.  The Templates/CSELements ares check-in the Version Control System.

3.  The Templates/CSElements are imported into the Development Server.

4.  Once the build is in the Development Server, it gets deployed to Management Server or (Test/QA Server) using WebCenter Sites Publishing Mechanism. From Management Server it gets deployed to Delivery Server again using WebCenter Sites publishing mechanism.


4. Developing Multiple Versions Concurrently



In addition to the set-up given in the earlier, developing multiple versions concurrently requires that you setup parallel development environment for different versions.


Say you want to work on both version 2 and version 3 in the development environment. You will need two development servers. The developers working on version 2, will download the version 2 template/cs-elements and other assets (asset types, definitions, site entry etc) for version 2 on their laptop or sandbox.


The developers working on version 3 will download the version 3 templates/cs-elements and other assets for version 3 on their laptop/sandbox. Both version 2 and 3 will use the same Version Control System. But Version 2 and version 3 have their own Development Servers. The templates, elements and other assets for version 2 are imported into Version 2 Development Server and templates, elements and other assets for version 3 are imported into Version 3 Development Server. The following diagram depicts this:



This setup allows developers to start developing version 3 while 2 is still being tested and is in the QA cycle.


5.    Conclusion



Thus we see that developing multiple versions concurrently in WebCenter Sites can easily be done by utilizing WebCenter Sites CSDT tool-kit, a version control system, and additional development servers.




  1. Vivek

    Do you know anyone actually doing it this way? We tired and the developers were baffled by the import export process, what assets were were, there were constantly import and export errors to debug and that slowed down developers when they spend a few hours of there day trying to figure out why some asset never imported.

    Basically the diagram you put out there is what we tried to do , but there were just so many issues with actually getting it to work.


  2. Randall Spicher says:

    I’d recommend that instead of having “version 3” dev server start publishing to the QA server, when version 3 is ready to become the “main stream”, you switch the current version 2 dev server to the version 3 branch, and then publish out from there. Think of it as having a “Beta” server (labeled as version 2 above) and an “Alpha” server. when the Alpha code is ready to become the Beta code, you move it (via CSDT) to the Beta server. That seems to work out better in practice than having multiple dev servers publishing to the same QA enviornment.

    Note you also do not need multiple laptops/desktops for the local devs, at least if you develop on JSKs. If you use JSK as your local platform, you simply need 2 JSKs (one for version2, one for version3) and 2 seperate Eclipse workspaces (one pointing at version2 and the other pointing at version3). Then you can swtich back and forth at your leisure. You could even run both simutaneously if you wanted (and have enough Memory!) by setting each JSK to a different port.

  3. Joe O'Malley says:

    Reading the article I’m not completely clear on the full lifecycle for the development of multiple versions. The last diagram shows multiple development environments one for each version. What happens to the version 3 code after it has been developed? Is it imported back to the version 2 development server and then published forwards to management and delivery server as shown in the earlier diagram or do you do something else?

    • Vivek Singh says:


      You will need one development environment for each of the concurrent versions that you want to develop. If you want to start development of version 3, while you are still working on version 1 and version 2, you will need a third development server for version 3. If you want to start on version 3, after you have stopped working on version 1, you can re-purpose development server for version 1 for developing version 3.

      Say the starting point for version 3 is the version 2.0x, and you no longer need version 1 in the development environment. In this case, you can import version 2.0x from version control system into development server used for version 1, and start making changes for version 3 in this system. When version 3 has been tested and QAed and is ready to be published to management, it can be published from version 3 development server to management.

      All publishing to delivery servers should be done from the management server. Before publishing version 3 to delivery, you should first publish version 3 to management either from version 3 development server, or from version 3 test/QA server – based on your organization’s procedures. Make sure all the content is ready for version 3. Then publish version 3 from management to delivery server.



      • Joe O'Malley says:

        Thanks Vivek, I think I understand now but is there any chance you could add a diagram that shows for instance 3 development streams therefore 3 QA environments converging on a single management and delivery server. Are there gotchas with this approach if you publish from 2 or 3 different QA servers into the same management server what can go wrong?

        • Vivek Singh says:


          The management server can not support both version 2 and version 3 at the same time. So let’s say you have management server with version 2 and your development server and QA servers are version 3. Now, when you are ready to publish version 3 to management server, you will need to publish ALL version 3 templates, cs elements, attributes, asset definitions site entry assets and other structural assets to management. You will need to make sure that your management server moves to version 3 completely. You can get a list of all changes for version 3 from version control system. All these assets need to be published to management to move management to version 3.

          Once you have moved management to version 3, there is not going back to version 2 (at least no easy way). So before moving your management server to version 3, you must be sure that you are not required to support version 2 in delivery.

          Also, management and delivery servers should be on the same version numbers. So once you upgrade management server to version 3, and your delivery server is on version 2, you will need to put a content freeze on delivery. You should not publish any content assets to delivery till delivery also moves to version 3.

          Coming to your question of “Are there gotchas with this approach if you publish from 2 or 3 different QA servers into the same management server what can go wrong?”:

          Essentially, you will not be publishing from version 2 qa and version 3 qa to management server in a mixed manner. When management is on version 2, you will only be publishing from qa version 2 to management server. At this stage you will not be publishing from version 3 qa server to management.

          Now when you are ready to move management to version 3, you will publish ALL version 3 changes to management. Subsequently, you will be publishing only from version 3 qa server to management server.

          There is a potential of a ID clash from a version 3 asset and version 2.x+ asset. In this case, you need to make sure that all your Templates, CS Element, site entry assets, attributes, site definitions, filters, and any other assets are same on the management server and the version 3 QA server. If any version 2.x+ asset has the same id as the version 3 asset, you should delete the version 2.x+ asset, and publish version 3 asset.

          Let me explain a little more about the id clash potential. If a version 2.x+ asset, and a different version 3 asset have the same asset id, there is a id clash. This possibility of id clash is small, because version 3 was seeded from version 2.x, and all version 3 assets had the same asset ids as version 2.x. However, it is possible that after seeding version 3 from version 2.x, you created a new template in version 2.x+, and published it to management. There is a possibility that the id of this version 2.x+ asset may clash with another version 3 asset.

          The best way to take care of this situation is in the development servers. Say you have version 2 development server, and you need to create version 3 development server. So you seed version 3 from version say 2.5. and create version 3 development server. After you have created version 3 development server, you need to create some new attributes and templates in version 2 development server. So now your version 2 development server is on version 2.6. After you have created new assets in version 2.6, its best that you publish them from version 2 development server to version 3 development server. Thus if there is any id clash, you will catch them at this time, in the development servers.

          I hope this clarifies your doubt.

  4. In this scenario developers have their own local OWCS, but this is tedious. CSDT allows to connect to a remote server, but every time an asset is saved, it is saved in the remote server, so two developers can modify and save the same Template/CSElement at the same time without any control. I miss the old revision tracking and I would like a similar solution to use CSDT connecting to a Development server. Is there any project to improve CSDT?

    • Vivek Singh says:


      WebCenter Sites revision tracking is not a version control system and has very limited capabilities. I do not know of any one who is using WebCenter Sites version control with CSDT. You should put a version control system in place, and use CDST with the version control system.

      If you have any suggestions for improving CSDT, please open a Service Request (SR) with Oracle Support. When the service request is opened, the support engineering will capture your request and create an Enhancemet Request (ER) on your behalf. WebCenter Sites Product Management looks at the ERs and prioritizes them.



Add Your Comment