cancel
Showing results for 
Search instead for 
Did you mean: 

Development Landscape ..or.. Version Control with Subversion

Former Member
0 Kudos

We have recently purchased xMII, and are starting to plan our deployment of it. One issue we are struggling with is how to lay our our development landscape. Our current thinking is as follows....

1) Each developer will have a separate IIS/xMII server (either on a Virtual Machine, or on a desktop).

2) The xMII template libraries and HTML libraries will be managed with a 3rd party product (the current preferred product at this site is 'Subversion').[/code]

3) Developers will 'refresh' their development environments by 'checking out' the appropriate xMII libraries from Subversion.

4) Formal software releases to QA will be done by copying the appropriate Template/HTML libraries from Subversion, which will then be used to re-populate the corresponding libraries in QA.

5) Formal software releases to Production will be done by cloning QA into the production space.

Is this a reasonable approach? Does anyone have a better idea? Is there something I am missing that will cause problems later?

Thanks so much for your feedback!

Accepted Solutions (1)

Accepted Solutions (1)

sufw
Active Participant
0 Kudos

Hi Ryan,

the approach you are describing sounds exactly like what we do as well. However, I do have one suggestion for your consideration.

Since xMII stores files relating to your application under three different directories (C:\Inetpub\wwwroot for web files, C:\Lighthammer for templates and transactions and C:\ServletExec\se-xMII for the 'portal' and login pages), commits to Subversion from the developer machines won't be atomic - that is files relating to a single report might need to separate commits - on Inetpub and Lighthammer and would thus be assigned 2 separate revision numbers.

This is a little bit of a pain when trying to roll-back changes or see who committed what.... So what we do is create an artificial root for the whole xMII deployment. In our case, this is called

C:xMIITrunk

. We use a tool called HardlinkShellExt (---> Google) to easily access the linking feature of the NTFS file system (I'm assuming you're running Win 2k or later as the dev environment). These links are essentially hardlinks in the *nix world and are completely transparent to the operating system and any applications.

So our setup looks like this:

C:\xMIITrunk contains the Inetpub, Lighthammer and ServletExec/se-xMII directories and their contents.

The

C:Inetpubwwwroot<company name>

directory is actually a hardlink to

C:xMIITrunkInetpubwwwroot<company name>

The

C:Lighthammer

directory is actually a hardlink to

C:xMIITrunkLighthammer<company name>

The

C:ServletExecse-xMII

directory is actually a hardlink to

C:xMIITrunkServletExecse-xMII<company name>

The xMII application works as before, since it goes accesses files at C:\Lighthammer, etc. and get transparently redirected (by the file system) to C:\xMIITrunk\Lighthammer and so on.

Updates and commits to and from subversion are easy since they are now performed on a single location (C:\xMIITrunk) and are truly atomic (e.g. related web files, templates and transactions are now committed together and with the same revision number). Since most of the ServletExec and Lighthammer directories (excl. log files and machine-specific config files) are all in Subversion, patches and updates to xMII are delivered using Subversion to all developer PCs and can be rolled back easily...

Obviously, this approach will require a bit of redesign and work when version 12 comes out, as a few things, such as file names and locations will probably change... Depending on what features v.12 has in this space, this might even become redundant. But the process described above has served us well for some time, and has handled the upgrade to 11.5.2 without problems.

Hope this helps,

Sascha

Former Member
0 Kudos

One other very important piece of advice I can give you regarding designing your applications for smooth migration to 12.0 is to use an identical folder structure for your templates, transactions, and web page content. This will make it much easier when migrating to 12.0 and creating deployable "packages" that include templates, BLS transactions, animated objects, and web page content.

Best regards,

Rick

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi, Ryan.

That should work fine. However, you might want to hold off on this, as some aspects of configuration management will be included in version 12.0 (and will be enhanced later in the year).

I'd suggest contacting Bimal Mehta in the xMII team (bimal.mehta at sap dot com) for info regarding the configuration management features in version 12.0.

- Rick