Please find attached the transcript for the March 2018 Release Deep Dive: New Deployment Workflow Walk Through video.
How to enable the new deployment option in training account?
Hi Sunil Rangaswamy. Great question. Adam Arrowsmith, are you able to provide guidance?
CC Nancy Kenney
Hi Sunil Ranagaswamy!
As of this time the training accounts will not be enabled with the new deployment. You can only have non-training accounts enabled by reaching out to your account or partner manager. Once the new deployment is available for general release, it will be enabled in the training accounts.
Please feel free to reach out if you have further questions.
Hi Nancy Kenney
It is good that Dell Boomi is starting to work with packages instead of deploying individual processes, but to me it seems that Dell Boomi trying to reinvent the deployment process. For example, I can create a package but I'm not able to deploy it afterwards. There is no package management option to work on a package level. There is no option to name the packages (now the name of the folder is used). There is no option to deploy/undeploy multiple packages at once.
I'm a software developer for over 20 years now. I have worked with C# and other OO languages, BizTalk, Pega Systems, and more. I'm learning MuleSoft and Dell Boomi at the moment. With Boomi I'm struggling with the concept that only processes are deployed and that related components are automatically included with the deployment. Why are these related component treated this way? Why is the link between the build and deployed process kept alive based on it's internal GUID? By doing this, moving/renaming processes and related components after they have been deployed makes things inconsistent, opaque and more sensitive to errors.
With kind regads,
Hey Dennis van Mierlo
I appreciate your follow-up questions and interest in this functionality. Although we are introducing some changes in the deployment workflow, it is with the ultimate goal of providing greater governance and insight into what and where components are deployed throughout your Boomi landscape. Understanding that the successful adoption of updated functionality requires an appropriate level of enablement, we will continue to provide videos and documentation as we introduce additional enhancements to Boomi and this area, in particular.
Many of the perceived limitations you've raised are, indeed, addressed through the updated workflow. A good resource that may provide some clarity is available here in the Reference Guide: Comparison of deployment tasks
Additionally, as communicated in the March 2018 Release:Highlights, we will continue to invest in providing enhanced tools and approaches for customers to automate the testing, packaging and deployment of their software artifacts.
I hope that's helpful.
So, to confirm, a package can only consist of one process/process router/etc. If I want to always deploy a set of 10 processes together (to "package" them as it were), that would still require me to deploy each in its own package (though could be done in mass as before). Is that accurate?
In the new Package Manager when you select multiple processes and choose Create -> New Package & Deploy, this will deploy all the selected processes and related components at once. When changing the filter to show processes with the status "Deployed" and select (not check) a process, you can see the related deployed package to that process. This gives you the option to undeploy a package, and all components in it.
Correct, just like when I could deploy multiple processes at the same time. So the main benefits of this change are the following:
However, the ability to package multiple processes and routers together into a bundle that can be tracked as one unit (similar to a build in the standard development cycle) is not possible. I still think the new packaging process is a move forward, but it's not quite the leap I was thinking it would be.
Retrieving data ...