nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Possible to have different versions of Components across Branches?

paultongyoo

Hello all,

We're looking to see if it's possible to work with different versions of the same set of SitePub Components across DEV, QA, STAGE, PROD branches, with each environment branch containing an arbitrary number of release branches (1.0, 1.1, 1.2, etc).

Would the general strategy for supporting this behavior be using the custom resolver to externalize the configuration XSL to a separate file that is maintained within each branch? We are currently only using the Appearance XSL and Content XML configurations (is there a way to externalize content XML config as well?).

Thanks for any advice!!

Paul

Find more posts tagged with

Comments

tec_iwov

the Component Picker all ways pulls from Staging of the component branch, you cannot apply a particular version though . But once the component is placed on the page it is tied to that version until you update the version via the get latest functionality. So technically you can multiple versions of the component running out in the wild.

there is a resolver build into livesite where you can pull xsl from the current work area, this is described in the developer guide.

you can externalize the content by using DCR's, see dev guide or on line help in the component editor for the DCR datum type, or you can create an external.

paultongyoo

Thanks much for your response, tec_iwov -- I totally didn't realize Content XML is "naturally" externalized via selected DCR's.

I'm curious if anyone out there has had success managing components across DEV/QA/PROD branches on the same TeamSite instance? I wonder what release strategies are out there to promote content up the stack?

For example, I am wondering if it makes sense to separate copies of components into DEV, QA, PROD directories to keep page authors from using components whose externalized dependencies have yet to be promoted to the next environment. I.E. Imagine an author creating/developing a new component with externalized XSL/DCR's. This component would also be visible to QA personnel via their QA branches and would appear potentially usable, however it would actually NOT be usable because its externalized files haven't been promoted to the QA branches. Keeping the component in a DEV folder might be a medieval way to indicate it isn't ready to use yet.

What do you guys think? What has worked for you?

Thanks again in advance!

Paul

NameIDLookupKeyField.rptdesign

kmu

With LiveSite I wouldn't recommend you having dev and qa/prod on the same box. This is definitely going to be painful to use - particularly when you start adding your custom java code (externals, controllers, etc.).

I'ld recommend creating seperate workareas for each component state and use permissions to hide components in development from non-developers. For versioning just put the component into a subfolder called 'Development' and move them into 'Testing' or 'Production' once you're done. You need to take care that you use the TeamSite workareas as intendended with LiveSite.

paultongyoo

With LiveSite I wouldn't recommend you having dev and qa/prod on the same box. This is definitely going to be painful to use - particularly when you start adding your custom java code (externals, controllers, etc.).

Where have you experienced the most pain? We are not adding custom Java code to our component configurations -- Just custom Appearance XSL (externalizable w/ custom resolver) and Appearance/Content XML.

I'ld recommend creating seperate workareas for each component state and use permissions to hide components in development from non-developers. For versioning just put the component into a subfolder called 'Development' and move them into 'Testing' or 'Production' once you're done. You need to take care that you use the TeamSite workareas as intendended with LiveSite.

Could you elaborate on what you mean by creating separate workareas for each "component state"? It sounds like we're on the same page regarding managing dev/qa/prod versions of components using separate directories/permissions.

What IS the general strategy suggested for using TS workareas "as intended" with LiveSite?

Thanks for your help!

Paul

tec_iwov

what your talking about is not currently feasible within Site Pub.

Components are only pulled from the staging area of the component branch.

You cannot make sub branches. only in the test branch can you pull from the component branch work areas.

paultongyoo

Hi tec_iwov,

I wasn't clear -- I am looking to create QA/DEV/PROD directories within Component STAGING that will maintain separate "versions" of each component. Promoting a component from DEV to QA theoretically means copying the .component file from DEV folder to QA folder.

How does this sound?

Paul

tec_iwov

that should work all though it's a manually intensive process of copying files around. It might be best to contact interwoven and get some recommendations.