Question procedure libraries

[jmac13]

Hi All, (I'm using open edge 10.2b)


I've been looking at procedure libraries as a possible method for us to deploy code (or a release) to site. Currently we will make changes to our code then zip up the source code and unzip it on site and compile it in a deployment folder. Then copy across the .r's to the live folder, to me this isn’t really the best solution. So I was looking at creating a procedure library that we updated and then we would copy that across instead.


I’ve got a few concerns about using procedure libraries (see below) and wondered if anyone has used them to deploy code and if so what are their experiences etc? I’ve seen in an older thread that Cringer said he used them so if you see this post let me know your thoughts.

A procedure library is a bit like a .dll file in that it is a single file containing a library of .r files. It saves you having to deploy hundreds of small files all the time. We tend to work on the basis of a library.pl that contains the last major release, and a patch.pl that contains anything that has changed since the release. If handled well this should make maintenance a lot easier in the long run.

On the plus side I can see that because programs are loaded into memory with .pl that you can deploy code without effecting users currently connected to the system. but also at the same time I could see an issue if say Program X was changed and user A loaded up a new session but user B hadn’t that they would be using 2 different versions of program X.

Also if we wanted to release a hot fix everyone would have to log out to get this.. is there anyway round this?


Thanks

 

[TomBascom]

Are you really deploying "hot fixes" into live production environments?

That sounds more like deploying "hot bugs" to me

Presuming that you run with -q in production (doesn't everyone?) the hot fix issue is no different than it is with regular r-code. If a user already has a session and they have already loaded the r-code they won't see your change.

Anyhow -- procedure libraries are a very common deployment mechanism. They are very useful and they work well for many people. You might have to consider bringing your ops & admin people into the 21st Century though. Maybe even implement a bit of change control process...

 

[Rob Fitzpatrick]

Maybe even implement a bit of change control process...

And you will need that process to keep you from causing problems for your users if you move to PLs. Because now you're no longer compiling against their DB schema. You're compiling against a schema-holder DB at your site that contains their schema. Obviously, you need process to ensure they remain in sync. And because you're compiling with your DLC, not theirs, you need to be aware of whether they're using 32-bit or 64-bit and use the appropriate compiler. And once they move to 11.x, your compile process has to be upgraded at the same time as 10.x r-code won't run in an 11.x runtime.

I'm not trying to discourage you by any means, as there are advantages to deploying PLs rather than source. But you need to think of the procedural consequences of deploying r-code and plan before you act.

 

[jmac13]

Hi Guys,

Thanks for the reply.. no Tom we don't have -q on (I'll have to look at this) and unfortunately we do release "hot fixes" into the live production . For Change Control we use source safe and a tracker system so we do have some tractability. but unfortunately we don't have subversion so no branching. From the sounds of it we should be working with a more static production system but I don't think we would change due to the "flexibility" it gives my boss to fire out changes to site. I was just trying to get a method of working out what version of software we've got on site.. but I think subversion needs to come first really

 

[RealHeavyDude]

What strikes me is that you compile at the customer site. This does only make sense when the database schema at the customer site differs ( or potentially differs ) from the one you use to build your releases against. Usually this would be the case when you allow your customer to make changes to the database schema to build their own custom logic that integrates with your application.

Most likely your concerns should not be around procedure libraries because they are widely used and proven to work. Your concern should be as to why you need to compile at the customer site and thus force your customers to buy a development license from Progress in order to be able to do so ...

Heavy Regards, RealHeavyDude.

 

[jmac13]

Hi RHD,

you are correct we shouldn't be compiling there.. I think its due to not being a 100% on what its currently on site and a legacy thing "we've always done it that way" Also as customers are on different "releases" which we don't really have a way to go back to... I guess this a bigger question than just about procedure libraries. I need to study ways of deploying in Open edge and formulate some kind of plan for us to work towards has anyone got any good docs they could point me at?

Thanks

 

[RealHeavyDude]

We use dedicated databases to compile against that only contain the schema and no other data. That allows us to keep many versions of them without wasting a lot of disk space and we're ready to compile any supported version ( in conjuction with source code management - we use Subversion ) that we need. We even check in a backup of these databases into the respective release in SVN.

Database changes are applied like this:

There is a time window in which the developers need to deploy their schema changes. Right before that time window we restore a backup of the compile database for that release to a different place and the developers deploy their changes to this database. When the time window has closed we produce a delta DF against the original compile database and apply it to the compile database for the new release. In the process we also maintain a sequence that allows as to identify the schema version in the database. Afterwards we build our rlease ( compile the source code ) against the new version of the compile database.
The schema changes to the individual production sites are then deployed with that DF that was applied to the compile database. That way we make sure that we won't have any CRC issues.

Maybe this is not the most sophisticated approach to but it works for us without a fuzz - we never had any CRC issues.

Heavy Regards, RealHeavyDude.

 

[jmac13]

Hi RHD,

Yeah thats sounds good..we don't really have an issue about DB's schemas being out of sync.. more the version of code is that is on the different sites.. but leads back to SVN.. I guess thats prob my first port of call

Thanks for the help