Allow more flexibility to Geocortex Web options with Deployment Mechanism
Terminée
RELEASED: Web 5.18
- Allow only certain items to get deployed from development > x
- Allow apps to share tools, so not all tools get stove piped into single apps when pushed to production. In other words, a tool common to web app A and web app B in development gets multiplied when pushed to production, so web app A and web app B each have their own version of the one tool in development that was deployed.
- See post for more details: https://communities.geocortex.com/s/question/0D55x00007xh9u7CAA/deployment-strategies-best-practices
-
Commentaire officiel
Hi Ryan,
The reason new Workflow, Reports, Prints, and Inline Views are made for each app and each deployment stage is that allows each App to be its own entity and unexpected changes won't happen in production. If multiple production apps referenced the same Workflow and a change broke that Workflow, then multiple production items would be broken.
Reading your other post, the goal for the Deployment Mechanism is for you and others on your team to not have to manage what's in the "Geocortex (do not delete)" folder. VertiGIS Studio Web Designer will clean up unused items in that folder on deployment. Do you find you and/or team managing that folder?
Regarding: "So if I have two Web apps with the same tool, each tool gets deployed as its own item. This can get very confusing if we want to update that tool. Seem like we need to re-deploy each app to push that out?" - Yes, re-deploying is the way to update the test (or staging or production) version of the Workflow/Report/Print/Inline View.
-
Hi Conner - thank you for the feedback. On paragraph one, I'd prefer to let us manage and worry about workflows breaking. There is much more work to manage a change to 20 copies of the same workflow than just fixing one. We would prefer no hand holding and let us control these.
On paragraph two, yes, we have to manage these at times. The main case being that workflows, when deployed to d>t>p, do not have their env variables changed like a web map does. We reference diff urls based on dev/test/prd servers in workflows.
On last paragraph - again, we'd like to avoid this scenario and have more flexibility. What if we have to push out a workflow for a break fix that is used in multiple viewers... but half of the viewers in development are not ready to overwrite what is in production? The work around is to just open the prod workflows and copy/paste all of the activities in from dev>prd.
The bottom line is we should be able to determine what gets pushed and what does not and have the ability to have a workflow shared between prd viewers like we do in dev. It is unrealistic to think we push apps and they are done or they never need to be revisited or modified.
0 -
Hi Ryan,
Thanks for the feedback. These are some good arguments that we'll take into consideration.
Do you feel the same pain with copies of the web maps/scenes / print-templates / reports? Or is this mainly a workflow problem?
Some good news, with the 5.17 release of Web, Workflows will have their env variables updated.
0 -
Thanks Conner! Appreciate the info. Looking fwd to testing 5.17 Web for deployment.
0 -
And also, yes, mainly a workflow problem.
-1
Vous devez vous connecter pour laisser un commentaire.
Commentaires
5 commentaires