GEAR 6 deployment related guide doesn�t mention about deployer. Can anyone provide me information about best practices for deploying an integration solution using webMethods Deployer?

Thanks,

Madhu

Hi Madhu,

I’m not aware of any best practices documentation for the Deployer. Thankfully the Deployer is a fairly straightforward product to use.

If you could give me some more information about the types of components you’re trying to deploy (e.g. Models or packages, or Portal objects, etc), then perhaps I could give you some specific advice about which options to choose and how to best construct your deployment sets.

Cheers,
Mike

Mike,

I am am just starting with Deployer 6.5 and would like some advice on the use for deploying Packages, Models and webMethods fixes to a master IS (propogating an IS patch to IS cluster and other IS in the domain).

Rajni

Hi Rajni,

Ok, here are a few thoughts. You’ve probably noticed that clustering isn’t automagically handled by the Deployer. We’ll be doing something smarter in our next release. For now, deploying the right bits to the right ISes requires a bit of manual effort.

Package deployment is fairly easy. Note that most of the IS-related Project options were put there for a reason. I’d suggest using them to suspend the various types of objects that might be affected by the deployment. I do not believe that any specific actions are required to deal with the fact that your ISes are clustered. Deploy the packages to all of them.

For Model deployment, you’ll want to deploy the Model information itself to just ONE IS, and then the IS Packages with all the logic to ALL the clustered ISes. So, do this:

1. In one Modeler Deployment set, add the Model and then all the underlying IS packages. Map this Deployment Set to the target IS in the cluster that has the WmMonitor and WmAdmin packages installed, and has the Logical-Physical server map defined from within WmAdmin.

2. In a separate IS Deployment Set, add all the underlying IS packages. Map this deployment set to the rest of the ISes in the cluster.

3. Deploy.

For IS Fix deployment, I don’t have one easy answer for you. It’s my understanding that fixes can take various forms. In general I can say that you’ll want to apply the fixes to the source IS, and then make sure you understand exactly what was in the fix. Is it a jar in IS/lib? Is it an updated .class file in a package? You should be able to deploy fixes like these. Either use the “webMethods Files” functionality or potentially deploy the affected IS Package. If, however, the fix requires the user to perform some logic or edits, then it may not be possible to deploy it. There really is no hard fast rule for deploying fixes.

And for all these types of deployment, be sure to do a Simulated deployment before the real thing. Read the simulation report and make sure that it’s what you expected to see. Although the simulation can’t catch all potential errors, it’s worth running.

Cheers,
Mike

Mike,

Thanks for the advise, I have some more question if you dont mind responding to.

1. There does not appear to be a rollback deployment support from the Deployer is this correct?

2. IS configuration deployment set, when deployed to target IS’s does Deployer change the configuration file content per target IS specifics?

3. Am I right in that deployment set can be exported from a say Development Deployer and placed under CM control and then this imported into a target Test/Production domain Deployer for deployment to ISs/Brokers in that domain.

4. Currently we manually take a Database dump of our Model from Development and import it to the target Test/Production database. I am assuming that we would not need to do this as Deployer will do this same action.

5. Does Deployer synchronise document types with IS broker when documents are deployed in target IS.

Thats it for now at least might think of some more questions later on having become more familiar with Deployer.

Thanks in advance for your help.
Rajni

Hi Rajni,

I will try to answer just some of your questions:

2. Can you clarify this question a little bit more?

3. This is correct. To ease the use of this feature you should avoid blanks in the name for the build.

4. Not Completely. Deployer transfers only the required runtime informations of the model, but not the design time information for Modeler.
   If you need design time information, export & (re-)import the model from/to Modeler.
   This should be the recommended approach for current deployment mechanism too, as Database-based deployment is not supported under 6.1.5. There were scripts for database deployment for 6.1, but they are not available for 6.1.5 and newer.

5. Yes! Check the deployment simulation report. It should state if sync takes place or not.

Regards,
Holger

Hi Rajni,

Here are your answers

1. Correct, the current version of Deployer does not have rollback. We plan to have this feature in the next version.

2. I’m not sure which configuration information you are referring to.

3. Yes. The Build page in Deployer has an option which will allow you to Export your build. You can then take this file and do whatever you want with it, including checking it into a version control system. You can then import it into another Deployer.

4. Correct, the Deployer handles the database portion of Model deployment. And, as Holger indicates in his reply, the Model deployment functionality only deploys the runtime portion of the Model and not the design-time portion.

5. The Deployer will synchronize the documents if that is requested. There is a project option that allows the user to request synchronization of All deployed documents, just the New deployed documents, or none.

Cheers,
Mike

Thanks, Holger and Mike,

Question 2) calrified:

What I meant to say is that if a Source IS is configured with appropriate setting for HTTP port, SSL and extended setting in the configuration files (server.cnf, port.cnf etc) then when a deployment set comprising of these files is deployed to a target IS will the Deployer change these files with known target values if they differ from the source IS, such as the pimary port number in server.cnf and port.cnf file.

Hope this is clearer.

Regards
Rajni

Hi Rajni,

Ah, that makes more sense. Good question.

I’d recommend NOT deploying those types of files. Instead, think about which pieces of functionality you want to deploy and select those objects instead of the files. Then you can perform variable substitution on the objects to ensure that they have the right values for your target environment.

For example, if you wanted to deploy an HTTP Port from your development machine to your production machine, you’d create a Deployment Set and then browse the Ports list in the Administration section of the Define page. This would be the best way to add the Port to the project rather than specifically including the Ports.cnf file.

Then, when you specify your target server on the Map page, click the Configure link to bring up the Variable Substitution page. This page will let you perform var-sub on objects like Ports (Extended Settings too!) so that you can change properties of the Port on the target machine.

I hope that makes sense.

Cheers,
Mike

Can i add a cluster of webMethods ISs to the deployment map instead of invidual IS instances

You can’t add a cluster per se, but you can select each individual IS and deploy to them togeter, but you can’t select a cluster itself.

Matt

In the 6.5.1 version of Deployer, released a few months ago, we included cluster support. Try installing that version and then reading the section in Chaper 1 (Concepts) about deploying to a cluster. You’ll no longer need to manually deploy to each machine in the cluster, if things are configured correctly.

Cheers,
Mike

Hello -

If you don’t mind, I’d like to piggy back on this thread as I also have a webMethods Deployer related question, more especifically, related to Configurable Items.

I understand that when deploying a build from a source to a target server, we can modify certain “Configurable Items” (ex. JDBC adapter connection parameters) during the Map step prior to deployment.

QUESTION: If we have a properties/configuration file that is part of the package (ex. in the config/ directory), can the properties within that file be configured in the same manner? If so, what steps must we take to accomplish that (ie. does the file have to be named a certain way? do the properties have to formatted in a certain fashion, ex. key=value? does the file have to be located in a certain location, ex. config/ directory?)

Thanks,
Percio

Hi webMethods Gurus,
I’ve found something very strange with Deployer. I’ve created a Project using deployer and exported the build. To my surprise, the build doesnt contain the adapter configuration substitutions I’ve made prior to export. The build only seems to take care of packages. Mapping and deployment configurations [that we use via ‘Save Substitions’ doesnt seem to get exported when we export the build. We want to preconfigure all the items before deploying… Is this possible?

This is working as designed. When you export a build, you’re just exporting the snapshot of packages, users, TN objects, etc. Basically this is all the stuff that you put into your project on the Define page. The variable substitution changes made on the Map page are not included in this.

The idea behind exporting builds is that some enterprises don’t have any network connectivity between their development systems and their production systems. So, we allow them to export their source objects from the Deployer on the Dev side of the firewall and then import these builds into a Deployer on the Prod side of the firewall.

Other folks use the export build functionality to squirrel away builds.

There is no supported way to export and save information entered on the Map and Deploy pages (but a clever inspection of the files generated by those actions might yield some clever shortcuts).

Hi Percio,

Unfortunately there is no functionality in the Deployer to support what you want to do. The list of items that can support variable substitution is limited and does not include files. This is a good feature request though.

It looks like you started working with webMethods 6.5 without prior
experience in earlier versions.

Please read documentation and practice a lot .

As such there is no such best practices in deployer .

Mike, I think it would be good to document Deployer best practices in the next release of GEAR (7.0?).

Hi,

we are just starting with deployer 6.5 and we like to deploy Integration Server components (Packages, users, port etc), Modeler components and TN components.
Our enviroment includes development, test and production systems.
What is best pratice to deploy between these different environments?

We plan to use one dedicated Integration Server for deployment.
Is it advisable to directly deploy a build from environment to test and after testing to production using the same build instead of exporting the build file, copy it, import it to the production system and deploy it there to production?

Thanks for any adivce
Michael

Hi Michael,

Although Deployer has many advantages, there are some dis-advantages you should take into account:

• If you don’t change version-number on every deployment of a (part of) a package, you will get lost to know what is deployed on which IS. We have several developers working on different projects, and I have no track on the status of generic packages (like our own util packages) on the different servers. There is not information on what has been deployed in a certain deployment (unless you’re willing to browse all the build-information anytiem you want to know something)

• Simulation does not catch all potential deployment errors. I.E. if a service on the target IS is locked by anyone, deployment of the anything in that package will fail, but this is not discoverd in the simulate phase (My opinion: it should)

Using 1 specific IS to deploy to all environments is possible, you should just set-up remote server connection between all IS and your deployer IS. We use a seperate deployer IS for DEV-TEST (for the developers) and for QA-PROD (for us support). By doing it this way developers have no reason to be on the QA and/or PROD system. They hand us the export of their deployer project.

I would strongly suggest to use the same build from DEV to all other environments. This is the only way you can assure that nothing has changed in the code in the deploymentpath (i.e. to make things work). Any environment specific instructions should be in some kind of release-notes, together with the deployment.

Kind regards,

Jeroen

Hi Jeroen,

thank you for your suggestions.
Do you use two seperate deployer IS one for DEV and the second for Test/QA?
Do you deploy from DEV to TEST, export the build file from DEV, import it to Test and deploy it from TEST to PROD? This is exactly the solution we were thinking about.

Kinde regards,
Michael

Michael,

Our development deployer is is used to promote from DEV environment to TEST environment. If it all works ok, the project is exported and imported in the deployer on QA.

From there it is deployed to the Qa environment first for user acceptance, and then on to the production environment.

By using this way the developers promote their own code to test. When they want it to be promoted to QA, they hand it over to support who is “owner” of the QA and PROD environment. Developers have (normally) no access to our QA and PROD.

Regards,

Jeroen