Source Control for Mercator Elements

[mlapse]

Hi,

Wanted to know which source control tool would be best for Mercator elements. We need a tool which would provide us with automatic deployment of Mercator elements.

Thanks!

 

[JuJutsu]

Source conmtrol programs don't automatically deploy. The control changes to the source. MS's product and PVCS have both been tested.



JuJutsu - Jeff S.
Support Analyst

 

[JuJutsu]

BTW, with later versions, you can deploy via scripts from command line.



JuJutsu - Jeff S.
Support Analyst

 

[mlapse]

Thanks. We use CVS as a repository and I want to make the deploy process such that I dont have to copy the files to the prod environment each time.

 

[JuJutsu]

I don't understand that statement. The deploy process _is_ copying the files to test or Q/A or production. If you make a change to a tree/map etc. and you don't deploy, the change does not go into effect.



JuJutsu - Jeff S.
Support Analyst

 

[mlapse]

What I mean is that currently our deploy process consists of manually copying the changed elements and moving them to production.

I would like to automate that process using an external 3rd party tool.

 

[JuJutsu]

Depending on the version you are running, there are command line tools with the product that can be called via a script. Also the IFD process is fairly automated. You have to know when a change has been made, then open the MSL and deploy. If the change is an added map, then you will manually have to add that map to an MSL, save and deploy. No matter what you do, it will require human intervention, to know when a change was made, you don't want an auto deploy process to run if there were no changes, on the chance that the FTP transfer could fail.


JuJutsu - Jeff S.
Support Analyst

 

[mlapse]

Thanks,

However the issue is with run maps. When I make a change to a run map, we are currently having to physically move the mmc into production.

we want to automate that particular process.

 

[janhes]

So what you want is something to automatically copy any changed map to your production environment. Sounds very dangerous. Also how do you automate restart of event server without compromising running processes.
You have to go through a change control process and this involves manual intervention somewhere.

 

[JuJutsu]

Any change should be sent to Q/A _long_ before you even think of going to production. This exact scenario caused a company to core dump and not be able to restart at 3AM Sunday. They changed a RUN map that was shared by a time triggered map and another map, but forgot the time triggered map and it was not compatible with what was done to the RUN map. Deployed on Tuesday and it ran OK until the once a week map ran. No one was on-site that could run slibclean or clean up the /tmp directory. Company was down for hours.



JuJutsu - Jeff S.
Support Analyst

 

[mlapse]

No I am not talking about automatically deploying the map to the production environment as soon as it is developed.

What I mean is, once the development has been completed and the elements are ready to be deployed, I should have the source control tool, on the click of a button, put all the elements into the production folder.

the restart is something we can do once the move has been verified as successful.

if i have 20 developers deploying their code on one day, i will have to copy many mmc, msl, mdq, mrn etc etc each time to production.

What i want is to have the developers put the compiled code into a deply folder once QA has been completed and then move it to production in one shot.

An example is Harvest which allows you to create a package and set the destination folders for the csource , compiled code and the config files. that way all I need to do is promote the package to production and all packages specified will move to production. then i restart the server.

This is less manual intervention and less chance of forgetting to copy something etc etc.

Thanks

 

[eyetry]

I assume your 20 developers will deploy their individual maps to a single test/qa environment before maps get packaged for production deployment. That way they get tested start to end confirming they work together.

Sounds like you might be talking about Integration Broker (IFD). You define your systems, event maps (& runmaps if you like) and deploy everything at one time. If your environment is setup properly the only thing you'd have to change is the deployment paths, from QA to Prod.

All sorts of ways to do it but essentially you end up with one package being deployed and all .mmc files where you want them with the click of the 'Deploy' icon.

If your ini file is configed properly changes to runmaps will not take effect until systems are restarted.

Problem is that there are advantages and disadvantages to any deployment process you use. You'll need to choose something and live with its shortcomings. Seems like everyone does it a little diff.

 

[JuJutsu]

Don't need to click on deploy if the maps are alreasy properly built, you can use the sdeploy comamnd line option.


JuJutsu - Jeff S.
Support Analyst