RE: [U2] Product Distribution Methods
First, my apologies for taking so long to respond to those who have offered their assistance. This is an "off the books" project I'm working on, so naturally as soon as I posted my original query everything else started catching fire. I've cut and pasted the responses so far so they all follow this message of mine; my original is embedded in at least one of the responses. I offered to take this discussion offline so as not to hog the digests, but the only comment on the subject was to leave it here so everyone can learn from the exchange. That's fine with me, so unless I hear some objections we'll keep it in the main list. Let me first explain the directory structure of our application. We set up what we call an environment, which is a collection of any number of data bases that use a common set of dictionaries and source code. Our clients can have as many different environments installed on their servers as they want; if they're doing things the way we suggest they'll have a production environment and a test environment, and the different environments can also be different versions of our application (there are other processing-related reasons to have different environments, but that's neither here nor there). In each environment we have three directories that are what I'll call "environment level" - one holds data common to the environment, one holds source code (clients don't get this one, but we have it in our office), and the third holds dictionaries, object code, and a handful of system-data files that can change with versions of the program. At the same level as these three directories, there will be at least one data base with the data files. As we make changes to our application components we create a record which sits only on the development servers. This record is a record of what version we made the change in, what file and program were changed, and to what clients it has been sent. We also have a means to promote items into a distribution package, which will be reflected in the distribution record. The key point is that we don't ship programs and dictionaries, per se; we specify which of these change records should be sent and our process determines where it should come from (development or distribution), based on a number of factors. Incidentally, each environment on each of our servers has its own client code, so we can track internal distribution, as well. The distribution process produces a set of seven directories and one file which get placed on the target server. An installation program within our application takes these files and copies the contents to the appropriate files in the client's system, cataloging programs and compiling dictionaries as required. We also have a process to simultaneously update the VOC files in all data bases in the same environment. Also, we catalog based on the environment, rather than the account, so one set of object code in one environment is cataloged only once and all the data bases in that environment point to the same physical chunk of code on the disk. Within the past year and a half we finally moved to a source control system that can handle development on UNIX servers (although most of our clients are now on Windows, we still do our development on UNIX - that's a long story, and a different conversion process). My hope is that our developers will be able to work independently on the same piece of code without stepping on each other's work (a third conversion process), but with our current distribution system I'll still need to copy their work to yet another environment from which to distribute. Since I'll have to do this anyway, I'm also hoping to leverage the source control system and do away with our internal distribution records, which are now redundant. This will entail a complete rewrite of our distribution system, though, which is why I'm interested in learning how others distribute their applications. Enough for now; this message is already getting too long. Just wanted to provide more information to clarify what I'm looking for and why. More to come. Dave Liesse SS&C Technologies, Inc. -- Date: Thu, 13 Sep 2007 07:50:22 -0400 From: Rex Gozar <[EMAIL PROTECTED]> Subject: Re: [U2] Product Distribution Methods Dave, My company markets a Universe application too, and like your company we have developed our own server-side distribution methods. When I think about the issue, it seems two-fold: (a) how do we get our software on the server in the first place, and (b) how do we keep it up to date with the latest and greatest? If I've misunderstood the problem that you want to discuss, you can just stop here and delete this email. (a) We actually keep our source code for our product in CVS, and we build new Universe accounts for our target platform. That includes creating the files,
Re: [U2] Product Distribution Methods
Dave, My company markets a Universe application too, and like your company we have developed our own server-side distribution methods. When I think about the issue, it seems two-fold: (a) how do we get our software on the server in the first place, and (b) how do we keep it up to date with the latest and greatest? If I've misunderstood the problem that you want to discuss, you can just stop here and delete this email. (a) We actually keep our source code for our product in CVS, and we build new Universe accounts for our target platform. That includes creating the files, loading the dictionaries and data, compiling the programs, etc. via our build scripts. The resulting accounts are zipped or tarred to place onto distribution media. We expect Universe to be installed separately from our product. (b) Updates are a bit trickier, since they have to dovetail into existing systems that have been modified. From CVS and scripts, we can generate patch files that can be installed. The "patch" program can detect the conflicts, or otherwise install the newer software. Right now, ours is an on-demand process, and would greatly benefit from a "windows update" type of automation. Personally, I would welcome an open source approach. As a community, we need to lower the "barriers to entry" in all aspects of U2 training, development, and operations. rex --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Product Distribution Methods
Brian Leach and U2Logic both have client/server-style U2 installers/packaging toolsets. I haven't tried either yet. But both look interesting and have slightly different approaches. See their respective websites for more info. http://www.brianleach.co.uk http://www.u2logic.com Regards, David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig Bennett Sent: Thursday, September 13, 2007 8:21 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Product Distribution Methods Hi Dave, > Our system is far too complex to describe here in a single email, but > I'd like to discuss the topic in general with anyone who needs to > distribute their server-based code to clients, whether external or > internal. I'm willing to provide specifics; I just don't want to bore > everyone else with a lengthy description here. > As far as you can why not keep this on the list -- I'm certainly interested. One procedure does come to mind for this if you are distributing to UV: - Create "Clean Install" Account(s) for your product. These accounts should have files dictionaries set up as though they were setup at the client just before you began any data entry or customisation for that particular client. These accounts might include only basic source code or just compiled object code (with stub files in place of the BASIC source so that you can use CATALOG). - Back these up using uvbackup - Create a customization script or program or write your install manual --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Product Distribution Methods
Hi Dave, Our system is far too complex to describe here in a single email, but I'd like to discuss the topic in general with anyone who needs to distribute their server-based code to clients, whether external or internal. I'm willing to provide specifics; I just don't want to bore everyone else with a lengthy description here. As far as you can why not keep this on the list -- I'm certainly interested. One procedure does come to mind for this if you are distributing to UV: - Create "Clean Install" Account(s) for your product. These accounts should have files dictionaries set up as though they were setup at the client just before you began any data entry or customisation for that particular client. These accounts might include only basic source code or just compiled object code (with stub files in place of the BASIC source so that you can use CATALOG). - Back these up using uvbackup - Create a customization script or program or write your install manual Now your installation procedure is: - Use uvrestore to create your clean install accounts on the client - Once this is done begin customization - compiling, cataloging, setting up UV.ACCOUNT entries etc. Either manual or via program/script. Having looked at install systems on various Unix and Linux systems and on various databases I'd say that outside Windows everything boils down to unpacking an archive, optionally compiling and scripting configuration. Sometimes with all steps controlled by a script or program, sometimes not. Examine the UV install procedure as an example of exactly this: - mount your tape/CD - restore data from this using cpio (the install script) - the install script then does further extraction and configuration - As well as this perform the other manual installation tasks (setting up users, directories etc). Craig --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Product Distribution Methods
David, I believe Brian Leach was working on a commercial delivery system. U2UG has a discussion about developing a freeware method and [AD] I, myself have half of one written [AD]. You should talk to Brian about his, as it is most likely the most complete option of the three. - Chuck Liesse, Dave wrote: My company publishes a software product for commercial distribution. It uses Universe on the server and a combination of VB flavors for the client. Long ago we developed a distribution system for the server side of things, but that was back when we were a server-only application. Now I'm afraid we're considerably behind the state of the art in our method of distributing the server software (no problem on the client), and I'd like to explore new approaches -- - Charles Barouch [EMAIL PROTECTED] Consulting --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
