Define "Development" and "Production" for your AGOL items

[JamesCrandall]

Simple question: How do you/your organization define "Production" version of WebMaps or WebApps?

Since this AGOL environment is so far removed from what a traditional software development shop might be operating under, how do you handle the requirements from admins and management for building, updating and deploying "Development", "Test" or "Production" versions of Web Map and Web Apps within your AGOL environment?

To start, I've come up with an initial list of properties for what defines a "development" version Web Map:

1. The name or other description or tag properties must contain the word "beta" in them.

2. Any services must be non-production (aka, pointing to "development" published services)

3. Sharing must only be at the Group level and not with the Organization or Public.

To define a "production" version Web Map:

1. The name, description or tag properties must not contain any reference to "beta" or "test" or other such description.

2. Any services must be production versions (aka the service urls must point to "production" end points).

3. Sharing can be at the Organization or Public setting.

Can anyone comment, add to, or modify this?  I am attempting to satisfy system admins and management with answering their question: "Is this Web Map in production or development?"

[BrianBaldwin]

One method that we have used for this is by using an Administrator account as the 'production' owner.  This has helped to ensure that any service, maps, apps that are in production will not be tweaked or accidentally deleted by users that have 'production' maps/apps items that they own. 

So, when a map or app is ready to move into production, make sure that it meets your criteria for tags, naming, logos, etc.  Then, change the ownership of all of the required items to the admin. account.

We have also created a 'staging' group where users can share maps and apps that are created but are still in development.

[JamesCrandall]

Thanks for your input, Brian!

Change in ownership is something we use as well (although I didn't list it), however is not the only requirement.  We've identified that we need a mix of attributes/properties of items along with specific versions of deployed items in order to apply the definitions of "production" and "development" or "test" and satisfy the question: "is this a production version?"

My OP only talked to Web Maps specifically, but we also have requirements to define "production" and "test" WebApp Builder applications, Web Maps, published services, Python scripting (eg, any ETL).  My hope for this thread was to solicit alternative approaches that apply to a host of different products that an organization publishes.

...or if ESRI has any specific guidance on this topic I'd love to see reference information!

Thanks again!

[JenniferRoberts]

I am also very curious about how other organizations are handling this.  I am trying to figure out a way to update production web apps without having to take them offline.  I needed to make some changes to an existing web app and had no way to make the changes and test them without either editing the production version or starting from scratch on a new web app.  Any suggestions?

[JamesCrandall]

Hi Jennifer!

To answer your question we are going to be maintaining separate "dev", "test" and "prod" versions of each Web AppBuilder application that we deploy to our AGOL environment.  This means that everything in my OP above needs to apply to each version as well.

Therefore only "production" services that are pointing to production data sources will be added to the prod Web Map source document and the "production" Web AppBuilder application using any of those resources.

Only "dev" services that are pointing to development data sources (eg, dev SDE environments), ETL scripting, etc will be resourced in "dev" web maps and apps.

We are starting to build a process for each, documenting each item (saving to our sharepoint), as well as creating workflow diagrams for each.  Also there are deployment documentation requirements that are associated with Web AppBuilder applications.

Just some food for thought.

[TimMinter]

Mr. Crandall!

We're defining on the fly as needs arise based on some simple principles:

• minimize moving parts and things to maintain - e.g. if we can get away with a "dev/test" environment instead of a "dev" and a "test" environment, then we do.
• enable self service for content contributors - this means that a contributor can have full ownership and control over their items in all environments.  they also have full responsibility for meeting quality and availability requirements.
• establish the opportunity for content consumers to form specific expectations of the content based on which environment they are using - in AGO, this means that we leave notes in the item description regarding availability, support, etc.

The different environments lend themselves to different service level agreements among different customer segments.  Each may or may not need to be publicly available.  So, "production" has the highest, firmest, bestest SLA for its intended consumers, while the "sandbox" environment's only guarantee is that it will be a mess when and if it's available.  So far, we have implemented these approaches:

• Open Data site:  create sandbox, development/test, and production OD sites.  Link to the prod OD site from the other environments and explain up front that the consumer does not want to be there.  Each site has its relative OD group and relative OD items.  So, when we're updating an item in prod, we do it in dev/test first, then test it until success, then do it in prod, test until success, and call it done.  two are exposed at the moment:
  • prod:  http://gdl.wadshs.opendata.arcgis.com/
  • dev/test:  http://gdldev.wadshs.opendata.arcgis.com/
• AGO data library:  access is only internal to our subscription, and we've created dev/test and prod groups and items.
• content contributors - typically we recommend that they utilize a content folder structure that mimics the targets (e.g. OD or data library) and environment(s).  So, folders for "OD dev/test" and "OD prod" items.

Also, an approach that we've seen others using, but haven't used ourselves yet is to purchase multiple AGO subscriptions.  Based on your description of taking ownership, you might consider a large AGO subscription (100?) for content contributors and a small (5?) subscription for a centrally managed "production" environment.

happy Tuesday,

tim

[JamesCrandall]

Thanks a bunch, Tim.

What specifically defines a "production" Web Map in your environment?  Or better yet, how do you answer the question: "Hey Tim....  When can we say that Web Map going to be in production?"

Your input is greatly appreciated!

[XanderBakker]

There is a related topic here: Recommendations for DEV, TEST, and PROD environments in ArcGIS Online

[JamesCrandall]

Thanks, Xander!

I noticed one thing that stood out from that seems quite different is that we've got specific directives to maintain what I describe as silo's of "versions" of various items.  That is we cannot just "switch" an Web AppBuilder Application to point to "production" sources/attributes -- the system admins want physical/virtual copies to exist.  Should a "prod" version go down for some reason then the "dev" version can be re-tooled rapidly to stand up a new prod version (if you think in terms of a SVN repository, it's complimentary to the idea of having specific tags of source code that gets deployed).

So if we're talking about Web AppBuilder apps there is an entire hierarchy of individual components that must be defined and exist in it's own silo.

"Development" Silo for a Web AppBuilder Application:

• Web AppBuilder App Published with "Beta" in the name (tags and description too), shared with specific group (business unit within the organization, or if shared with entire org or public then it MUST sunset at a future date), owned by developer, and deployed to "test" endpoint (url must contain "test" in the name).
• Web Map source published with "Beta" in the name (tags and description too), shared with specific group (business unit within the organization, or if shared with entire org or public then it MUST sunset at a future date), owned by developer or steward, contain services pointing to non-production SDE/FGDB or hosted FeatuerService and published to a non-production endpoint (eg, "test" or "dev" AGS deployment).
• ETL or other scripting deployed to non-production endpoints, servers or environments.

It's definitely a challenge to inventory, document and create individual deployments for the various environments, whether those environments are physical, virtual, hosted or otherwise non-locational in nature.

Thanks again!

[TimMinter]

edit:  hmm.  maybe the geonet advanced editor isn't in production yet.  it seems to have removed many words up front...

edit 2:  many words abandoned in favor of deploying another system to production.

----------------

excellent question...  So far, what we've made up goes somewhat like this:

Bases

• The IT-centric information delivery context continuum extends from long-term operational phase, fiercely controlled systems to ephemeral mechanisms.  "Production" has to be relative to the requirements of the system within its information delivery context along that continuum.  (this statement is totally up for negation, refinement, adjustment, etc.  it stems from our recognition that biz & tech changes are spinning faster and faster)
• Esri provides AGO as a service to its paying customers.  We pay money to receive the service under a defined service level agreement.  That service level agreement defines and constrains what we can define as "production" when using that service.  e.g. we cannot refuse or delay a change to specific AGO features that may create changes for our system.
• "Map" in the AGO environment means a set of resources and configuration settings delivered in JSON format and renderable as a visual re-presentation that we have come to perceive as a spatial and/or geospatial re-presentation of real or imaginary objects (careful, don't look too far down here...  there's quantum foam somewhere below us )
• "Production" means that the map owners have generally agreed not to change it without coordinating the change with stakeholders who have made their needs known

When is an AGO map in production?

• when its referenced resources are in production (e.g. the basemap, the operational layers, the ancillary layers, etc.)
  • if we control the resources, then we can enforce this definition as fiercely as we need to (e.g. a map that certain staff use to change the operational status of one or more offices)
  • if we don't control the resources, then we have decided that the benefit of using them outweighs the cost and risk of having to react to sudden changes (e.g. a map that emergency managers use to form an operational picture in relation to emergent hazards such as wildfires.  Our organization does not map wildfires, but we need them from an organization that does.  we have no control over the changes that are made to the wildfire service other than maybe voicing a feeble "hey" when a change occurs that messes us up.)
• when it has an assigned go-to person - an author - someone to serve the needs of stakeholders with whom an agreement has been made to manage change requirements.
• when that author has met certain requirements that we have established (e.g. complete FGDC CSDGM metadata for all of the data sources that our organization owns, complete map item description elements we identified)
• when the map has been completed based on functional and non-functional requirements (e.g. the operational layers support editor tracking in an enterprise geodatabase;  the map resources, configuration, and access exposure meet information security requirements)

After all that digital wind, here's a simple example of a web map that we have said is in production:

• http://www.arcgis.com/sharing/rest/content/items/73ffa1b71a654ffe8e31a604cce98cc0?f=pjson

BTW - this is a great discussion topic you've raised.

tim