I don't understand deployment
I've been reading the documentation and several threads on deployment stages and I really just don't understand it. It sounds like moving an app to different stages creates copies of every workflow, web map, report and print template. Then it seems like when you make changes, all of this needs to be deployed again. I've read that you can exclude items from deployment but there are apparently consequences there. And then there are environmental variables, which I also don't understand.
Is there better documentation somewhere to explain this to a non-developer?
Is there any real reason why I can't just distribute the link to my developed “dev” app? I get that I would be skipping having any kind of test environment, but I don't have one now with GVH and it's always worked fine.
-
Hi Heather Widlund
You absolutely can share a link to a “dev” version of a VSW application, it will function just the same as production.
And yes, you are correct that the Deployment Stages create separate copies of the items involved in your application. The benefit of that is that you get a distinct version of your app (e.g. a production version) that is separate from development and therefore you can maintain and continue changing the development version while production is nice and stable.
This contrasts with, back in the day, where users would often use the Geocortex Essentials Manager to copy a site and make a “production" version, or even just manually copy the files. This would often create conflicts and cause issues, so Deployment Stages are our approach to solving that by having Designer handle that for you behind the scenes.
1 -
@... Thank you for your response! I'm a little leery of NOT deploying to prod because the VSW application seems a little less bomb-proof than GE/GVH, but I don't want to over-engineer, either.
I'd be interested to hear from customers who have followed either path and what the app management has been like.
0 -
I can understand leeriness. I would consider whether, for the specific app in question, some criteria:
- is the application meant to be public facing?
- do you intend to change and extend the application over time?
- is the application supporting business-critical operations?
If the answer to any of these is yes, I would suggest that using Deployment Stages has merit. Though, I am similarly curious to hear feedback from users in the wild as to their experiences using Deployment Stages in their VS implementations.
0 -
Hi Heather/Gareth,
We have two ArcGIS Enterprise environments (Dev and Prod) and deploy apps through 4 stages - dev and test, which are both on our dev environment and staging and prod, which are both on our prod environment. It may seem a bit over engineered but there it covers all of our needs:
- Dev allows us to develop and maintain our apps without impacting our users
- Test allows us to give access to a limited user group to test new tools/features and provide us with feedback
- Staging allows us to thoroughly test the app after it has been deployed to our Prod environment and open it up to a larger test group if needed
- Prod is open to all of the users in our organisation
As far as we're concerned there is one major drawback over GE. With the GE method we could put up a site that had no features/tools and displayed a message that told users we were updating the platform. With VGS there is no way of doing that without altering the app json, so even though we put out messages we are aware that some users try to use the prod app whilst we are updating it and get annoyed by momentary drops in the app performance.
In terms of app file management, the copies of items are all put into the same VertiGIS folder on our Enterprise environments. I tried to do some kind of management/categorisation on these files, but the sheer volume of them makes it unsustainable. They just get left in the folder.
One annoyance is that if VertiGIS roll out an update it will update through all of the deployments. Generally this isn't an issue, but where a breaking change has occurred our prod app will stop working (which has caused issues in the past). It would be nice if we were given the opportunity to test the updates in dev and then deploy them through to prod when we were satisfied with them.
Environment Values come into play when we are deploying from Dev Enterprise to Prod Enterprise. It works like a find and replace on the json so it allows us to change the portal url and item IDs of our data (for example).
Hope that helps
1 -
I've been confused about deployment strategy from the beginning. For example
I have this app here: VertiGIS Studio Web. I added a couple of layers and re-deployed the app
and I don't see the layers that I added… Not sure what's going on I'm definitely missing something.I'll do some more test and reach out to support but I find deployments confusing in general.
0 -
Cattyann Campbell That's why I haven't deployed yet. I'm not sure what happens to all the components when you need to update the app. There's the app, webmap, workflows, print templates, reports… How does all that get managed?
0 -
So yesterday I updated the app in question and I started with the web map added a couple of layers changed symbology, saved and the changes were there. I didn't push the deploy button just saved. If you push deploy it changes the URL. Today I went to add printing routine and big error came up. Apparently printing is deployed via ArcGIS Server Enterprise no Printing on AGOL. Not sure why this changed but we're paying for an app that no longer works that requires us to spin up a server just for printing. They could have left simple printing engine in there. I'm not setting up a whole new Enterprise server just for printing. Very disappointed in this change.
0 -
Cattyann Campbell Cam Barnard
What the heck? I'm completely on SaaS and planned to move forward that way, but now I'm getting a print template error as well. Is Cattyann correct that we can't print anymore on the SaaS deployment?
0 -
Heather Widlund … to be clear printing (gen1 via templates) is still available and supported in VertiGIS SaaS infrastructure, and we are working on printing (gen2 via templates) which will be available in VertiGIS SaaS later this year.
For sanity I just ran a quick print test completely in VertiGIS SaaS Web / Printing successfully.
1 -
Hi Cattyann Campbell and Heather Widlund
Apologies for the inconvenience, we were having temporary issues with our SaaS Printing service. Our SaaS team has addressed the issue, and Printing should be functional again. If you are still seeing errors, please let us know.
0 -
I am unable to complete a print job, but I have a support ticket in and will follow up that way. Thanks, Alisa Lindley
0 -
Printing is resolved for me.
Back to the topic, thank you Helen Dornan for your response. That's more extensive infrastructure than I have to deal with, but I understand why you would do it that way. I just don't understand the mechanics of it and what I need to do if I want to, say, do a simple dev to prod deployment containing all those components.
Do you deploy each component like workflows from its designer? Or does it all get wrapped up in the Web deployment? Does anything happen to the data layer item ids that I reference in Workflow? Or the report item ids that I also reference in Workflow? If I edit layers or symbology in the dev web map, per Cattyann's comment, how does that get deployed?
0 -
Heather Widlund - hopefully this will explain things a bit better
For sake of ease let's assume you only have one environment (so one version of AGOL/Enterprise) in this case you can largely ignore the Environment Values section. When you click on Deploy in Studio Web it gathers all of the components of your app (i.e. your webmap, workflows, print templates etc) and creates a copy of them and saves it to your environment. It will also create a new URL for you to view your app. When you view your app through the new URL you are looking at the copies of your app files, not the original ones that you are viewing in Studio Web/Workflow etc. This is what will allow you to continue to develop your app without impacting your users - as long as you make sure that they view the app through the new URL and are therefore using the copies you created during deployment. Each deployment overwrites the copies it created last time. This also means that for your users to see an update on your webmap you need to replace the webmap copy by re-deploying your app in VertiGIS Studio.
In my experience (although others can correct me if I'm wrong) the only thing that doesn't get copied is your data. In our current scenario the environment is the same and therefore your layer IDs etc will also remain the same. If you are deploying into a different environment (like we do with a Dev Enterprise environment and a completely separate Prod Enterprise environment) then your data needs to be in both environments. Undoubtedly this will cause a change in the layer IDs and that is where environment values come into play.
1 -
Helen Dornan
This is the clearest I've seen this written, thank you. It seems like if this is the case, I could deploy it to production (I'm just using AGOL) and see if everything still works, since I can always distribute the dev link if I decide not to do the dev-prod route. Thanks again!
0 -
When a solution (web, workflow, etc.) gets deployed from DEV→ TEST → Prod what is the expected behavior for the AGOL item metadata (Title, summary, description, terms of use, credits, and tags)? Do all or some of that text get copied over? Is there a way to define which text to migrate and which to keep as-is?
The behavior seems to vary for different applications I've developed over the year. Sometimes it overwrites the entries and other times it keeps it the same. Maybe I haven't experimented enough to see a pattern.
Cheers,
Mike
0 -
Mike Diss-Torrance
In general, when a new portal item is first created (i.e. the first time you deploy from Dev to Prod) we ‘clone’ the portal item, so the majority of information should be copied over. Once that portal item is created, the only thing we keep track of is the GUID to the item. Subsequent deployments won't affect any of the metadata on the item (we open it up to update the interior i.e. give it new app.config JSON). This allows you to update all metadata, thumbnail, title, etc. after the Prod item is created and ensure it won't be modified on subsequent updates.
0 -
Can you provide some more specifics as to what is and isn't expected to be copied over? I'm mainly asking so I can pass on the guidance to others, and what they should expect and look out for.
I just ran another test with Web version 5.33.0 and also with 5.36.0. For the first deployment, the title and description were copied over, but the other items did not (summary, terms of use, Tags, credits).
Subsequent deployments didn't overwrite them. However, are you aware of any situations where those entries would be overwritten?
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
17 commentaires