multiple connection types per module
There is currently no way to include multiple connection types in a single module. Combined with the inability to include multiple modules in a single .zip, this is starting to create duplication/bloat in our solution.
I can separate the connection types from the modules altogether and manage any updates (delete + add) independently, but that's even more bifurcation.
Before going down that path, I'm curious if better management for connection types is planned to better suit these use cases?
Thanks for posting this suggestion.
In terms of recent improvements in connection type management, we now have a way to remove a connection type using remove-azurermautomationconnectiontype cmdlet, and an API for removal: https://msdn.microsoft.com/en-us/library/azure/mt163852.aspx.
It sounds like you want to create multiple connection types which you can do using our API only right now: https://msdn.microsoft.com/en-us/library/azure/mt163818.aspx.
Can you explain a bit more about why creating and importing modules separately causes code bloat? I’m trying to understand what your module content looks like and how you manage this content to better understand why multiple modules and connections in 1 zip file are needed.
joe brockhaus (rax) commented
The recent "Azure Automation C# SDK for Azure Resource Manager" release (2.0) makes management of these much simpler. Thanks!
joe brockhaus (rax) commented
Originally, we wanted to build a single module that would contain just a handful of cmdlets that our Runbooks require. Because those cmdlets work against a variety of systems with various connection requirements, we need to be able to create multiple connection types.
Code bloat may have been a bit overstated. As we moved from what we thought would be path of least resistance to authoring our module, we were jumping through more and more hoops, writing more of our own project/build/deployment boilerplate that was getting spread across our source/devops stack. The bloat has come from the need to create multiple projects, splitting up and in some cases duplicating code across modules, and writing our own build/package scripts for each, all to create multiple connection types that are defined alongside the code that is dependent on them.
The PowerShell extensions project types don't offer much value to us, in that they don't manage the manifest definition or module dependency output & packaging. For similar reasons, creating and managing nested modules also did not seem like the best decision either - it just adds even more work. (And does AAutomation support nested packages identically to local PowerShell?)
In order to relatively seamlessly (for now, with minimal effort) create and maintain our modules with ConnectionTypes, we've settled on separate csproj's where we need separate connection types & post-build powershell to actually build the modules, pulling in dependent assemblies, etc.
I was not aware of the remove-azurermautomationconnectiontype cmdlet - we had been directly calling the API to handle this.
I also realize some of this is really outside the scope of Azure Automation, being more specific to PowerShell Module creation in general.
If the [ModuleName]-Automation.json file could support an array of ConnectionType elements, instead of (/in addition to) just a single one, almost all of this extra work would go away. Of course, until updating these types via these definition files is supported as part of module import, we still need the devops code to do that manually.