Ebase Development Setup and Source Control

[Andy McMaster]

Hi,

New to forums and Ebase and just in the early processes of setting up a server/development environment. Had the basic training course last week which answered a few questions but thought I'd pose them here for a more definitive answer!

1. Source Control - what are people using for this? I'd planned on using the Export directory structure etc. and using this as a basis for setting up a repository in subversion? Any suggestions on best way to do this and handle globals and resources etc. as well would be much appreciated.

2. Server setup for development, test and production. Again, best practice?

Cheers

Andy

[Joost]

1. Source Control - what are people using for this? I'd planned on using the Export directory structure etc. and using this as a basis for setting up a repository in subversion? Any suggestions on best way to do this and handle globals and resources etc. as well would be much appreciated.

I haven't tried it yet, but I'm thinking of a similar setup as you describe. As for the source control software I'm looking at SVN and GIT.

2. Server setup for development, test and production. Again, best practice?

Make it seperate systems and keep webcontext the same. Use environment vars or DB entries to store/manage paths, emailaddresses, etc. which are different on the dev, tst and prd environments. Use scripts to manage the web.xml and ufssetup.properties between environments. Use war file to deploy files. A release may contain XML export, war file and sql scripts.

I don't know if it's a proven best practice yet, so I'm open to suggestions.

[Andy McMaster]

Hi,

Thanks for the reply.

I've used SVN for an old ASP app. and it's worked great there. Still looking at rolling it out on other projects though. What I've seen I like.

Re setup:

Made a start on this and currently have three instances of ebase set up: production, test and development. Each has it's own instance of tomcat running on a different port. Currently looking to get each instance if tomcat running as a windows service.

I'm new to Tomcat so not sure if this is the best way to go?

Make it seperate systems and keep webcontext the same. Use environment vars or DB entries to store/manage paths, emailaddresses, etc. which are different on the dev, tst and prd environments. Use scripts to manage the web.xml and ufssetup.properties between environments. Use war file to deploy files. A release may contain XML export, war file and sql scripts.

Could you elaborate a little on this please? As I've got it now it doesn't seem straightforward to move an app between say test and production?

Cheers

Andy

[Joost]

Make it seperate systems and keep webcontext the same. Use environment vars or DB entries to store/manage paths, emailaddresses, etc. which are different on the dev, tst and prd environments. Use scripts to manage the web.xml and ufssetup.properties between environments. Use war file to deploy files. A release may contain XML export, war file and sql scripts.

Could you elaborate a little on this please? As I've got it now it doesn't seem straightforward to move an app between say test and production?

An app consists of Ebase elements (form, resources, etc), filesystem files (images, jsp, web.xml, ufs.xml, etc) and if you use a database db-tables.

When you move an app from one environment to the other you have to copy / recreate those.

On early setups I created in one tomcat instance two Ebase environments / webcontexts "development" and "test". In the filesystem I created directories like "d:\generatedfiles\development\pdf" and "d:\generatedfiles\test\pdf".

Now when moving a form from one environment to the other it's not a simple task of exporting the Ebase elements, but after importing them I have to check paths in various resources.

By keeping the systems alike, it's less work.

Exporting Ebase elements is explained in the Ebase documentation. More info on WAR files can be found in the Tomcat manual or on wikipedia "Sun WAR". SQL is explained at www.w3schools.com


Perhaps in the (near) future a deployment system becomes a part of Ebase which would ease moving forms from one system to the other. But till then the steps mentioned have to do.


Besides this the only thing missing at the moment is a way to undo a deployment. I now have to use a copy of the production environment or a backup to restore a test or dev env to it's previous state.

Perhaps a function which does a negative import and instead of adding/overwriting, deletes the elements. Or the import routine should create an export copy of all elements it imports before the actual import.

[Andy McMaster]

An app consists of Ebase elements (form, resources, etc), filesystem files (images, jsp, web.xml, ufs.xml, etc) and if you use a database db-tables.

When you move an app from one environment to the other you have to copy / recreate those.

On early setups I created in one tomcat instance two Ebase environments / webcontexts "development" and "test". In the filesystem I created directories like "d:\generatedfiles\development\pdf" and "d:\generatedfiles\test\pdf".

Now when moving a form from one environment to the other it's not a simple task of exporting the Ebase elements, but after importing them I have to check paths in various resources.

By keeping the systems alike, it's less work.

Exporting Ebase elements is explained in the Ebase documentation. More info on WAR files can be found in the Tomcat manual or on wikipedia "Sun WAR". SQL is explained at www.w3schools.com

I may look at writing something to try and automate it.

Perhaps in the (near) future a deployment system becomes a part of Ebase which would ease moving forms from one system to the other. But till then the steps mentioned have to do.

Besides this the only thing missing at the moment is a way to undo a deployment. I now have to use a copy of the production environment or a backup to restore a test or dev env to it's previous state.

Perhaps a function which does a negative import and instead of adding/overwriting, deletes the elements. Or the import routine should create an export copy of all elements it imports before the actual import.

There really ought to be an easier deployment option. Being new to the system it may take me a while to sort out the best way of doing things. I've raised a similar question re Service Packs which seem to be rather tortuous to install.

Thanks again for the reply. It's helpful.

Andy