Aller au contenu principal

VS Web / Workflow, and Source Control - any ideas?

Gareth Finney

Hi folks. 

We're currently transitioning our fairly comprehensive Essentials instance across to VSWeb/Workflow, and one of the questions I'm getting asked is how do we also transition our github-deploy-centric architecture to the new world.

We've had github for source control for years now and deploy - via jenkins - to any of our 4 environments (dev/uat/training/production) via scripts that essentially repoint urls, database links etc. A relatively simple concept, but we're scratching our heads a little with VS Studio.

Ideally we need 3 team members simultaneously updating components in either VSWeb Designer or VS Workflow, and then changes made make their way to source control (github), and then deployed to any of our environment portals (including potential active/passive configuration, which could be another discussion in itself!)

Our experiences with Portal so far is somewhat underwhelming with respect to having things actually ‘physically editable' for want of a better term, like you used to do with site.xml, or viewer json files. These were easy to get to, overwrite etc, and makes deployment pipelines so much easier.

I'm keen to hear from the community, if anyone has managed to..

a. Implement some form of source control, with multiple team members developing in VSW products

b. Implement some form of deployment option that can read from said source control (say github) and publish changes to x number of portal/vsw installs.

I've started to play around with the deployment offering in VSWeb, and from my first glance, it's a decent start, but does not read from github. The team, and management here are looking for other options that align to their beliefs of full CI/CD/ deployment pipelines. 

TIA

Gareth

2

Commentaires

3 commentaires

Date Votes
  • Gareth Evans

    Hi Gareth Finney 
    I have noted similar restrictiveness in my brief search around this topic. My understanding is that much of the context here is governed by the VertiGIS Studio platform on ArcGIS systems.

    The ArcGIS Architecture Center has some consideration around DevOps and Continuous Integration / Continuous Deployment under DevOps, CI/CD and ArcGIS:
     


    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.


     

    0
  • Gareth Finney

    Thanks for the reply @... - it makes for interesting reading, and I'm not all that sure our management are going to be all that happy with Esri's stance on this - it's a key requirement of our systems. I don't necessarily agree with it all of it, but I need to sell some sort of deployment methodology - even if it's using the OOTB vertigis web deployment. It's a start at least. It seems that Portal ‘can’ be scripted somewhat using the Esri Python API, but not I'm not sure if the VSWeb/Workflow/etc. components can be scripted? Is the VS API/SDK open to firstly saving files to source control (even to local files), and then ‘posting’ back in the portal for deployment purposes (ie. another portal?)

    I hope all that makes sense.

    cheers

    GF

    0
  • Gareth Evans

    Hi Gareth,

    Thank you for your follow-up question about deployment methodology and source control integration with VertiGIS Studio products in an ArcGIS Enterprise environment.

    Current Capabilities

    1. ArcGIS Python API: You're correct that this provides scripting capabilities for Portal automation, which can be valuable for your deployment process.
    2. VertiGIS Studio API: The platform offers programmatic interactions with applications, though direct "save to source control" functionality isn't built in as a primary feature.
    3. Environment Migration: Moving configurations between different Portal instances (dev/test/prod) is possible through export/import mechanisms that can be incorporated into your deployment strategy.

    Industry Context & Product Reality

    Our product teams at VertiGIS have been using CI/CD patterns for years in the development of all our products. However, VertiGIS Studio as an end-user product doesn't currently prescribe specific CI/CD functionality or patterns. This is partly due to:

    • The commercial off-the-shelf (COTS) pattern of ArcGIS
    • Our typical customer being a busy GIS administrator who prioritizes getting applications deployed quickly and may be challenged to manage complex CI/CD pipelines

    I recognize that CI/CD practices combined with containerization have become the expected standard for enterprise software today. The GIS ecosystem is evolving in this direction, though at a different pace than other technology sectors.

    VertiGIS Studio Web SDK Considerations

    While I'm not personally familiar with implementing the VertiGIS Studio Web SDK in a CI/CD pipeline context, I do know that it produces static web content that could participate in a deployment pipeline. One important consideration in this approach is handling authentication with secured ArcGIS services, which remains a requirement even in a CI/CD context.

    Potential Resources

    Esri provides guidance on automated deployments for ArcGIS Enterprise:

    To provide the most effective suggestions, I'd like to know more about:

    • Are you deploying to cloud infrastructure or on-premises?
    • What would your ideal outcome look like? (Static web application backed by content from ArcGIS Enterprise, or something different?)

    Even without perfect alignment to traditional development workflows, we can likely establish a structured approach providing the governance and repeatability your organization needs through a combination of available APIs, export/import capabilities, and carefully designed automation scripts.

    Looking forward to hearing more about your specific requirements.

    0

Vous devez vous connecter pour laisser un commentaire.

Ce n’est pas ce que vous cherchez ?

Nouvelle publication