Hi,
We are developing the code on our Dev env. We need to move the code to the testing and then to Production envs. How do we move the code from one IS server to another.
I understand that we can do this by archiving the packages, copying the file from the present Outbound folder to the target Inbound folder and then installing it. Does this process migrate the User Groups, ACLs, schedulers and all other stuff.
Does the above process replicate whole of Dev environment? Whats the best way to do this.
Theres a component called webMethods Deployer. Does that help me in the migration process.
Basically lot of users follow different procedures when deploying the packages from different environments Dev to(Staging,Production etc…)
like automated (pub/sub),manual process …
Recently webMethods Announced “webMethods Deployer 6.1”.This info is available in Advantage website under BookShelf/CurrentRelease section and look for “webMethods Deployer 6.1” link.And see the release notes.
Deployer is very powerful, but also a bit complex until you get the hang of it. It appears to be designed for large organizations with frequent deployments (builds), many target server environments and a need for unattended operation (once the deployment specifics are set).
For that reason, I don’t think Deployer is a good fit for simple things like moving an IS package from one server to another and making a few config changes.
It is, however, the best way that I know of to automate the deployment of server configuration information, adapter configuration information, port, user and ACL information. One of the many features I found helpful is the ability to specify overrides for these configuration settings for a specific environment such as shared development, integration test, QA, production, another geographic location, etc.
The most recent Deployer news item is that you can now use it to deploy process models created with Modeler.
So, in short, Deployer is very flexible and designed for tougher deployment problems. If you need to do something simple, you might find yourself frustrated by the complexity that comes with that flexibility. Hmmm. Another target for Graham’s “ease of use” evangelism.
We write custom Ant build files for our packages that zip the contents of a package and put the archive in the inbound directory of the necessary integration servers via FTP. We even replace the “node.ndf” files of adapter connections dynamically dependent on the environment the package will be deployed to (test, prod…) by setting up different build targets.
I will take a look at wM Deployer, maybe it does what we solved with our build files …