Hi,
My client want to use a new datamodell and have only a few services in each package and instead have many packages, maybe 300.
Would you say this is ok? How many packages do you guys have in your installations? Whats a big wM installation when it comes to number of packages?
I know its important to keep them “clean” and not have dependencies between packages, only to a few common packages. Still all packages needs to be loaded at start and all manifest files be processed.
/J
Hi,
this depends on how the content of the package is organized.
Additionally you should make sure that the box has enough memory and that it is configured for the IS.
We have split our installation in 5 IS instances operating independently against the same database but different schema.
They share the same Broker for messaging and the same MWS for monitoring.
For the custom tasks which are needed on all instances we have developed some shared packages which contain i.e. housekeeping, error handling, custom administrative support tools.
Dependencies between packages are important when it gets to maintaining load order of the package to avoid services or triggers being started/activated before the neccessary connections or documents are enabled or loaded.
Load time increases with the number of packages as well as the number of nodes inside the packages.
Regards,
Holger
Hi,
How many packages have you seen on one IS? I think the load time will be the critical part for us.
Hi,
in total we have about 100 custom packages across all 5 instances, from which 7 exist an all 5 instances (sometimes with partially different contenct).
These 7 packages contain Adapter Connections, Adapter Listeners, shared documents, shared functionality like i.e. housekeeping and adminstrative support.
Some of the 100 cusotm packages will never be delivered to higher environments as they contain development unit tests or backup functionality for development environment. Some of them will only be delivered to internal test environments to ease testing before handing the code over to QA and prodution environments.
Unfortunately the amout of packages is not equally spread across the instances. The load time during startup differs between 1 and 6 minutes depending on which instance is being started.
Additionally each of the 5 instances is equipped with the same set of packages provided by wM (Default, PSUtilities, WmTransformationServer, Wm*), 35 per instance.
Regards,
Holger
Hi Mr. Jake,
We have about 270 custom packages. A few are for housekeeping, utilities shared among the other packages, adapters, etc. The other custom packages are organized according to the content. For example, publishing sales order canonical is one package. Subscribing by System A is a package. Subscribing by System B is a different package. There are no dependencies among these three packages. All the services in each are specific to that package’s functionality or, if they are not, they are in the shared utilities/adapters packages. This works well for us and the startup load time, performance, is not adversely impacted.
I don’t know that load time at startup is a reason to have fewer packages. However, ongoing maintenance and deployment favors more packages if that is needed to support the application function/content.
Regards,
Mary
Hi,
In general Mary is right, but there are some conditions where dependencies should be specified.
These can be identified when shutting down the IS and then perform a clean start with a fresh log file (rename the old one before).
I.e. packages with adapter services/notifications/listeners should only be loaded when the package with adapter connections has been loaded. Another example is when you have packages with triggers subscribing to a publishable document in another package, the package with the publishable doctype needs to be loaded first to avoid an error message during the activation of the trigger that the local doctype definition is not yet available.
Regards,
Holger
Hi,
I agree Holger that dependencies are important to always have in mind.
My conclusion over the years is that we often have the problem that the packages contains too many services and it ends up in slow deployment process and it becomes difficult to have a continuous integration approach.
Therefore, we are considering a larger number of packages with less services that can simplify development and deployment.
Regards
Hi,
it is not neccessary to deploy the complete package all the time.
You can only deploy the changed services as a patch instead of a full deployment.
There is no formula how to compute the right number of nodes per package as this also depends on the size of the nodes.
Regards,
Holger
Hello everyone,
I thinks that in the latest releases SAG did a lot of work towards CI and DevOps. See: GitHub - SoftwareAG/sagdevops-ci-assets: Software AG DevOps library to support assets CI (continuous integration) with webMethods 9.x and 10.0. Work together with https://github.com/SoftwareAG/webmethods-sample-project-layout
For package dependencies it is always a good idea to state them upfront, i.e add them to the service meta-data. This way, if deploying multiple packages at once WmDeployer will know the correct deployment order.
@Holger: is there some documentation with regards to the patch deployment. I want to dive more into this. I usually do full package deployments without taking into account how small or big my changes are.
Thank you.
Hi Vlad,
this dependents on how many team members are currenlty working on the same packages.
When you know exactly that you are the only one and know what changed this might be feasible.
But if there several developers on different parts of a package and you have to deliver a certain part and the other parts under development are not yet ready for deployment, it is advisable to use patch deployments and only deliver the parts already finalized.
Deployer-Users Guide should have some informations on this.
As we have quite a large application spread over 5 (mostly) independent IntegrationServers separared in a dozen parts we only want to deliver the parts that have definitely changed without delivering parts which should have remained unchanged but you never know exactly until the next source code review.
Regards,
Holger
My understanding is that if we’re talking about CI and DevOps then we should use a version control system and the repository based (RBD) deployment (not the runtime one). Which makes the deployment of the full package the only option IMO since RBD can only deploy full packages.
If you need quick deployments of smaller parts your only option is to make packages smaller.
Correct me please if my understanding is wrong.
Hi,
as we are currently only doing Runtime based Deployments this works for us.
If I remember right, Repository based Deployments were never mentioned in this thread before the last post of fml2.
Regards,
Holger