Until today, to deploy some web services or parts/elements of web services (ex : documents, service flow), I used to create One Project, each time for One build (For each projects, I have a one only build).
But, looking the Deployer structure, I’ve realized, I could make many Builds for the same project.
So, to deploy a new element (ex : a document has changes) I’ve tried this new way to in using an existing project :
I’ve created a new (second) Set
(Warning one first Line : Project definition has changed since the Build : → that seems normal)
I’ve created a new (second) Build line version
I’ve created a new (second) Deployment Map line and associated the Target IS
I’ve created a new (second) Deployment Candidat
But after the last step I’m obtaining a new warning :
“The Deployment Map associated with this Deployment Candidate contains partially mapped Target Server(s)/Group(s)”
So I’ve many questions :
Why this last warning ? I verified : the Set#2 is well associated
Is it really a good pratice to create new builds inside a same project ?
Im assuming that in the second map you left the map for the 1st set blank and webMethods is reminding you that you may have missed a set.
but as long as you are sure that you do not want to map the original set you should be good
The way i do it is whenevere i have multiple sets ,the second set us usually contains elements exclusive to those in the first set ,but part of the same logical project.(Eg Process model in one set abd the implementation code in the other)
That way I keep the sets clean and easier to handle dependency checking and less number of mapping lines required.
Each time i would deploy the whole shebang to ensure build sanity.(You can always roll-back if you dont like it)
There was at lease one use case where we had to use a different set/Project while deploying TN components to a Cluster.as the backend database in a cluster is the same.This was with 9.8 i think.Not sure how the behaviour is for higher versions.
I’ve moved a service from a directory to another directory.
Then I want to redeploy my service.
So, I’ve kept my existing Deployer project,
I’ve created a new (third) Set
I’ve created a new (third) Build
but when Deployer tried to compile, it throwed me an error : [DEP.0001.0041] Deployment set IS has unresolved dependencies and could result in an incomplete deployment. Use the Deployer user interface to resolve the dependencies
And after, the previous build are placed in warning mode (yellow icon)
And I can’t do anything to make my build compilable
The only (bad) way I found, to repair it, was :
to modify the 2 previous Sets, and re unloading/loadind service (because of the missing moved file),
to rebuild tje 2 previous Builds
anf then the last Build can compile (green check).
I’m not satisfied with that because I did not want to modify my previous Builds.
In this case, what is the problem please ?
Is it a Deployer bug… or is normal ?
in this case, am I obliged to create a new project (for a such a litle modification) ?
when creating additional sets it is expected behaviour that previous build become yellow.
They are marked as “Project definition changed since time of build”.
As the third Set will only contain the new service you should go “Check dependencies” and find out which other objects (services, documents, …) it is referring to. Usually these can be marked as “Exists” as they have been deployed earlier.
As you said you have moved the service you will need to delete the old service.
To do so go the properties of the package and fill the files to delete section.
For a flow service specify the files in following order:
ns/path to service/node.ndf
ns/path to service/flow.xml
ns/path to service/flow.xml.bak
ns/path to service itself
The other option to delete services is to create a deletion set in deployer and specify the service. But this requires the old service to be still present on source environment.
See Deployer Users Guide for further informations.
Yes I understand that the previous builds become yellow as “Project definition changed since time of build”.
But it my case, creating a new Build throwed an error (red icone) because of unresolved dependencies. [DEP.0001.0041] Deployment set IS has unresolved dependencies and could result in an incomplete deployment. Use the Deployer user interface to resolve the dependencies
but for the concerned Set (the last one) I’ve verifyed that all the dependencies were resolved (the chek was green after selected ‘Exists’).
and despite of the green checking set, the last Build stayed red (even after rebuilding).
So, I suspect my new Build was in error because of the others previous sets ( yellow) and builds (because of the file moved).
this is expected behaviour, as the previous sets still have references to the old service.
You will have to re-resolve the dependencies for this service.
There should be no need to rebuild the previous builds.
We are currently following a different approach:
When the changes to our applications exceed a certain amount of nodes affected or if we have to migrate from one platform to another, we produce a set of Builds with new major version (project names contain the version number) and Builds are named Initial_Build to indicate that this build serves as a base line for upcoming builds of the same application part. Together with these intial builds we also deliver the neccessary configuration and properties files.
For minor changes we produce additional projects where the sets only contain the latest changes for particular implementation tasks and then the build will be named Partial to indicate that it only contains neccessary nodes and should be deloyed in order of the minor versions (if there several of them for one specific application part) on top of the last major version.
Each of these projects only contain build and will never be touched again.
This increases the number of projects to be created in Deployer but reduces irritations like “Project definition changed” or builds failing due to outdated dependency resolutions.
I really hope, I do not need to Rebuild the previous Builds. I will try again, you’re probably right, so I would just need to resolve previsous sets.
I unfortunately did not find any useful informations in the official “9-8_Deployer_Users_Guide” about the way to do with major, minor version, and multi bulids.
So I’m creating a way to do, getting first, from all your advices and differents forum links and web articles.
For examples, the only doc I’ve found about Deployer’s naming conventions are these ones :
I think, there is a real lack in the official Deployment webMethods guides…
So here is what I do :
Project :
0001_WS_PART_26012017
IS_Set1 (new service A)
→ Build : V1.1.16
→ MAP : Preproduction-dep1
→ Deployment : V1.1.16_Preproduction-dep1