Auto Deployment - Every file change

Masters,

We had a need of deploying all static files which will be modified by other teams and uploaded to teamsite almost instantly to our DEV environment (web/app) servers. Having too many DEV instances and each DEV instance. have respective workarea in teamsite. I have implemented a custom script and made it a cron job which runs every minute during workhours to synch particular folders with remote servers. All was well until server started hunging. Since there is a lot of traffic running every minute and atleast there were five OD jobs running at an ymoment of time, adding any admin activity on top of it to teamsite causing teamsite hungs, if not responded in time had to restart machine which is lokcing stores including workflow admin and to bring it back to normal running state has become a pain.

So, I'm looking for a new approach to retire my current one something with event tracking or using triggers such a way that anytime if a file is modified update only that single file instead of comparing all files with remote servers which mostly includes unmodified files. Any best practises or similar experience sharing is helpful.

Thanks

Find more posts tagged with

Comments

archanavonteddu

Did you say you have multiple Dev TS instances? Can you please elaborate your requirement including the TS Env. info

and also did you try using iwat triggers (createfse/modifyfse) to run a script when a file is created/edited and you can retrieve the files that were modified from the arguments it gives back and run your workflow/deployment based on it.

Thanks
Archie

ISCBorisB

anytime [...] file is modified [deploy] only that single file

1. You may perhaps start by improving your existing approach instead of discarding it completely.
Try to serialize concurrent transactional deployments, see if that helps. Check OD Administration Guide
and KB 61497 for some details.

By the same token, you can make your 'cron' job smarter. Check if there is anything to Deploy in the first
place before actually starting useless deployments. You can do that for example by publishing/comparing source
Editions, etc...

2. Alternatively, consider enforcing some discipline into ad-hoc modifications of shared static resources.
Ideally, you may control the whole process through dedicated Workflows with Deployment tasks that
utilize FileList mode to deploy only Files attached to these WFs.

Simplest flavor of this approach is probably to create a WF (or Custom Menu Item) that performs only Deployment
and teach your Contributors to check out desired Files and execute when they are ready.

3. Finally, you may trigger Assets promotion transparently by coding custom Event handlers on System's
Events like CreateFSE, ModifyFSE and whatnot.

Take a look at "iwat" and related commands. Note that this sort of processing is global and usually requires
some extra coding to recognize/ignore tons of CreateFSE/ModifyFSE/whatever Events that are unrelated to
your task.

sheikh1

@Archie - The multiple instances are DEV web/app instances for which I have setup workareas in DEV TeamSite. We are at latest and greatest release of I/A version 7.3.2.
Since you suggested iwat triggers, I had a negative feedback from one of the users because of performance issues, do you know whether using triggers is a scalable and light weight process or not, I'm looking at this since the amount of resources we are dealing is huge in number of files though not much in size wise?

@ISCBorisB - Great pointers, especially the first option, until now I decided not to version files for some other reasons but I think I can make use of this for atleast comparsion. I'm also thinging to generate some checksum otherwise. The second option is not suitable for us since users don't want to login in to teamsite to publish their changes and they have their own jenkins script which pushes updates to TeamSite on demand, I will weigh on the third option as well.

Thanks to you both.