Infrastructure as code

Many organizations have started to consider or have already begun to deploy IT infrastructure through code-based definitions, often referred to as Infrastructure as code (IaC). The process of doing so typically involves the following steps:

1. Select an automation language, such as CloudFormation, Terraform, ARM templates, Bicep, or others
2. Define a variety of infrastructure settings, such as the virtual network configuration, a virtual machine’s specifications, and inbound load balancers or reverse proxies
3. Run the “build” of that environment from a manual user-initiated tool or other automated process

The result of the IaC deployment is a set of resources that could be deployed successfully by hand, selecting individual configurations and settings, but through IaC can be deployed with strong consistency, automatically re-deployed, or adjusted slightly to conform to new specifications.

ArcGIS is generally compatible with many IaC approaches and systems, which are often designed to work within a specific cloud environment or system, such as AWS CloudFormation, Azure ARM templates or GCP Cloud Deployment Manager. Esri also builds tooling for certain providers, specifically AWS CloudFormation templates and Azure ARM templates, which can be used as a foundation for further configuration or extended.

Once infrastructure is deployed using an IaC provider or tool, ArcGIS software can be either manually or automatically deployed to these systems. See Automate ArcGIS software deployment for details.

Some IaC patterns are designed for frequent deployment where changes are pushed to the infrastructure frequently or whenever that code changes. This pattern can be difficult to align with ArcGIS systems as both ArcGIS Pro and ArcGIS Enterprise rely on a relatively stable and consistent network and infrastructure environment. Therefore, if IaC changes are required, it is recommended to either carefully proceed with those changes as with any change to an Enterprise IT system (plan, test, review, adjust), or that these systems be combined with other DevOps-style tools that enable software deployment automation, so the entire system can be rebuilt and deployed on a regular cadence.

IaC and ArcGIS

Additional suggestions for working with Infrastructure as Code alongside ArcGIS include:

• IaC is an excellent tool for maintaining infrastructure and baseline configurations, but not for maintaining state of a system. The “state” of an ArcGIS system includes users, items, content, services, and data. While IaC can lay down appropriate “hardware” and installation of the software, the restoration of state to a system can be complex and time consuming.
• Using IaC to deploy the hardware early in a project (or for a new environment) is more straightforward than trying to update an existing environment. Updates might adjust network configurations, machine naming, storage or firewall rules, or other conditions that the software relies on, and if the software is unaware of, or unprepared for that change, these infrastructure-level change could lead to instability or service disruption. As an analogy, if a working ArcGIS system is a car, traveling down the street, you wouldn’t expect to swap the tires of the car mid-stream, or change from gas to diesel while the engine was running.
• Other IaC languages or providers are likely compatible with ArcGIS. In general, when reviewing a potential IaC approach, consider the manual configuration steps that are needed for the hardware and infrastructure, attempt to automate those sequentially, and move on to software deployment and configuration once that is complete.

DevOps, CI/CD and ArcGIS

DevOps, as a term, generally refers to a code-driven deployment workflow, where commits or releases automatically deploy something, replacing what was there before. Other terms used in this area include continuous integration or CI, and continuous deployment or CD, often combined as CI/CD. These terms come from the world of software engineering and the building of application development and custom software applications, where continuous deployment and testing are used to support the release of software.

ArcGIS is a commercial off-the-shelf software package, and as such it is somewhat misaligned to many organizations’ existing use of CI/CD or DevOps for custom application development. ArcGIS, once deployed, begins to create state and configurations in ArcGIS Enterprise, the portal content, services, user content, configurations. Re-deploying ArcGIS Enterprise or a new ArcGIS Online organization destroys that existing state unless a backup is restored, so you can no longer view what you created.

For DevOps to be successfully used with ArcGIS systems, an organization needs to either:

• Maintain a quite rigid deployment with fixed set of contents, or carefully managed content, which you can automate the deployment of from a “blank” system. For example, a single viewer application that includes a static set of file-based data can be deployed on a nightly basis, including automatically publishing or updating web services.
• Identify a reliable way to extract state, for example with WebGISDR, redeploy the system components and base configuration, and then redeploy state.