This is a continuation of previous articles on IaC shortcomings and resolutions. The networking resources for private plane connectivity are ubiquitous and several within any deployment. As the deployment grows with age, the versions of the toolset and definitions also change. New properties are added while the old ones are deprecated. Subnets, for instance, can be created with different definitions and property values but with the same module. By nature of subnets delegated to a resource type, there will be several within a virtual network used with a deployment. When the new properties are added to the definition, many of the existing properties might require an opposite value with these new properties while the others might work with the default value. The same goes for different environments where the module is applied. Changing the definitions might pose a risk across many resources that are hosted on the subnets. If there are disruptions, they could manifest in different scenarios,

This could be overcome by staging the changes progressively and in an incremental manner such that the round of tests is minimized and only applies to the changes made. The first step should be to update the toolset before any changes are made  Many of the existing resource types might need adjustments with new toolsets although backward compatibility if a standard feature as toolset versions is incremented. Once this is done, the existing definitions must be assigned to a reference for their source before a new definition is used. If they do not have a reference, they will likely point to the latest and updating the source to a new definition will affect more resources than intended. Next, the common definition must be updated, and a new tag must be generated so that it can be referenced only from those callers that require the new definition. One the reference is available, all the resources in the deployment that require the new definition must point to the new reference. Then their properties must be replaced with new properties in such a way that there is no change to the current infrastructure. Some of this might be counterintuitive in terms of say Boolean values assigned to certain properties but the goal must be to have no changes to the infrastructure after complying with the new syntax. This way there will not be a need to test all the resources attached to the subnets, which is quite a daunting task. Finally, changes must be made on a case-by-case basis so that those cases can be tested independent of the overall infrastructure. When all the changes have been made to revise the infrastructure, the definitions, the resource properties, and the fine tunings to individual resources, then a closure can be applied by setting up alerts and notifications as the resource-types demand. 

One of the advantages of making selective changes is that the business can weigh in on their priorities and release dates. It does not need to be done all at once and it might even be beneficial to get their acceptance after each change. The requirements from the business usually affect one or more environments, so prioritizing by environment is a natural order. It is also possible to include the changes compare resources from different scenarios which will inevitably help with troubleshooting unexpected behaviors from deployed resources. Together with the scenarios and infrastructure, it would be easier to narrow down the potential issues and determine the course of action for their resolutions. Similarly, we can leverage the compiler planning and execution stages to spot errors before they are caught by actual testing. 

In this way, changes affect several dozens of resources can be made in a safe and efficient manner.