Many organizations use separate development, staging, and production environments to maintain the quality of their websites. When used in your ArcGIS Enterprise organization, those environments are often set up as follows:
- Development—This is a sandbox environment, where you can test your applications and services without impacting your development environment. Typically, the development environment runs on a small machine, disconnected from the production ArcGIS Enterprise environment. Once changes are validated on the development environment, they are applied to the staging environment.
- Staging—This environment is a clone or other approximation of the production environment. A staging environment is used to build and test Value Added Applications and map caches; conduct user acceptance, performance, and load testing of other third-party software; stage new commercial data updates; and conduct training activities. Testing at this level results in a decision to apply the changes on the production environment, or reject the changes and wait for a new iteration from the development environment. The staging site is not used for development; it is only used for performance and functional testing. Esri provides staging licenses for ArcGIS Enterprise at a lower cost than production licenses.
- Production—No development or testing occurs on this environment, given that GIS users (and, in some cases, the public) access it. Only changes that have passed the scrutiny of testing on the staging site are applied to the production site.
The development, staging, and production environments ideally use different databases and infrastructures. Each organization has its own rules for how changes are tested and approved across the environments.
See the ArcGIS Architecture Center Environment isolation topic for more information.
Moving a change from environment to environment can present logistical challenges. This help topic provides patterns and scripts to guide you through the process, whether your ArcGIS Server site is federated with a portal or stands alone.
Note:
This topic discusses considerations for ArcGIS Server in development, staging, and production environments. It does not cover other ArcGIS Enterprise components.
Configure each environment
In each environment, install ArcGIS Server, create a site, and configure security, server object extensions (SOEs), and other settings. Most of these tasks are faster if performed manually, although they can also be automated with a script.
Get your development site working first and create the staging site, followed by the production site.
Deploy services
The key to deploying services in multiple environments is to register your folders and databases correctly with ArcGIS Server and use service definitions (SDs) for publishing.
Register folders and databases with ArcGIS Server
When you register a folder or database with ArcGIS Server, you provide the publisher’s path to the data and the server’s path.
- The publisher’s path is the data path on the machine you’ll use to make the SD files. The publisher’s path is always the same when you register an item on the development, staging, and production servers.
- The server’s path is the data path on the server. This path can vary when you register an item on the development, staging, and production servers.
If you have many data folders or databases to register, you may consider using scripts.
Publish services
Use SD files when deploying your services in multiple environments. The SD takes the information needed to publish a service and packages it into one file. Although it’s possible to package the GIS data within the SD, it is recommended that you preload the data in each environment and use replication to keep it in sync.
Create connection-neutral SD files (choose the No available connection option in the Save a Service Definition wizard dialog box) so they are flexible enough to be published on any server. When you publish an SD file, ArcGIS Server automatically corrects the paths written in the SD file so that your server paths are used. Careful data registration allows you to deploy the same SD file in multiple environments.
Publishing services is a task well-suited for scripting. You can use the ArcPy function Upload Service Definition to create a script that will publish each SD.
After deploying your services from the SDs, enable any extensions required by the services. This can be done manually or through scripting.
Another task that can be scripted is applying permissions to various services as listed in a text file.
Update services
You can update a service to use new properties or reflect changes in the source document. It is recommended that you update a service in multiple environments by saving a new SD file, deleting the service, and publishing the updated SD.
When you take this approach, the same example script used above for publishing can also perform service updates. Modify the input file to include only the services you want to update. If an existing service is found, the script deletes it before uploading the SD.
After you update a service in this way, reenable any SOEs used by the service.
You can alternatively script updates to service properties (but not the map or source document) using the ArcGIS REST API.
Keep data in sync
Ensure your data is kept in sync across your multiple environments. Geodatabase replication can help you with this. Alternatively, you can replace the old dataset with a new dataset. For example, you can delete a file geodatabase and replace it with an updated file geodatabase.
If you decide to entirely replace tables or file geodatabases, remember that ArcGIS Server services lock the schemas of the underlying datasets by default. If the schema is locked, stop your service before you can replace the data. With some degree of caution, you can disable schema locking for map services, but you can’t disable it for other service types.
Update applications
To move an application between the development, staging, and production environments, copy the application files from one site to the other and update any web service URLs in your code so they point at the new site. Use configuration files to define the URLs for your services.