This is a very open-ended question, but hopefully, we’ll spur on some good conversation.
I work for a large financial institution which is only relevant in that there are strict migration policies as code moves into production.
We are relatively inexperienced with this process and I would appreciate your notes, tips, and pitfalls associated with the process.
This is a large problem for many companies because Network Administrators are a part of the solution. Typically, these folks are not involved with the webMethods Sales Cycles nor are they involved in the day-to-day development of B2B code. When it is time for code migration, the Network Administrators get a crash course in B2B Server and, typically, balk at the out-of-the-box process of copying ZIP files, for example.
How do you move code from machine to machine? Thanks for sharing, everyone.
Dan,
we can do the migration process by defining
different instances of b2bserver runnning at diff
ports say for dev,test,prod and eventually move
our code to these envirnonments.
Thanks for your feedback. Let me pose a different scenario, though. What if your environments are physical located on different machines and in different locations and with different security protocols? I can see the value in changing the target ports if one machine acted as the B2B Server instance for all four environments, but what if that is not the case?
How have Network Administrators asked that you promote code to the next environment? Have you been able to import packages as ZIP files? Has a change in flows’ Internal Invoke settings been required? What about ACL usage? Have there been additional port restrictions and IP Deny settings required?
Although we have not implement webMethods yet we are planning to use PVCS with
embedded scripts that will leverage the webMethods import and export capabilities to move .ADO files. This is just one issue in a long list of challenges on how to implement new systems into the corporate environment where cultural and behavior habits are impacted. Is there anyone else planning on using PVCS for webMethods software promotions?
Our current implemention on version control of migration for packages is just to create additional folders for each versions, as our migrator is not technically experienced with webMethods product. Quite a headache, but unfortunately, version control using package management efforts can only be visible upon installing the package, and viewing the info from the web Manager. Therefore, each folders have been categorised based on the version number of each package.
Dan, I am also at a large financial institution and we are using a product called Harvest for source/version control. In addition to allowing us to do standard source control stuff (ie. checkin, chechout, diffs, etc…) the product will allow designated (authorized) people in our organization (eg. Developers, support) to move the components through the stages (Dev, QA, and Prod) and/or demote components. The product will also copy the components to various servers via scripting. This is “easy” for Integration Server since we know the inbound packages need to be put in <is>/replicate/inbound, however for ES integration components/adapters this is not as easy. To ease the pain we will create adapter configuration (MS Word) documents containing installation/setup/config info for each adapter. These docs will be used by our support people doing the deployments.
The Harvest product will take care of notifying the appropriate people when they need to do something. For example, the QA deployers will be emailed when the code gets promoted to the “QA deploy” state and needs to be installed. The QA testers will get emailed after the release is installed.
If you want to chat further please let me know.