What are people doing to mimic a Development to QA to Production migration?
We are relatively new to Workiva and would like to know what others are doing when setting up their Workiva system. We are very familiar with having multiple environments and then promoting change through each environment. Example Development for Development of the source information, QA for testing, and Production for the actual production run.
Are people using different workspaces and then manually copying the changes to different workspaces (environments)? Are people using one workspace, but having different ENVs (Environments)? There seems to be issues on either approach, the former can't migrate code except manually, the later, the security for the chains is the same and thus there is some risk of editing Production accidentally.
Is there another option or how do you mitigate issues on your approach?
-
Clearview gets this question a lot from the Workiva customers we implement for. In most cases, we develop new functionality (e.g. Wdata, Wdesk Objects, etc.) within the existing Workspace. Functionality like Wdata Connectors, Chains, Tables, and Queries have no impact on a customer’s existing Wdesk environment until the Query is connected to a Spreadsheet. So our typical approach is to make a copy of the latest version of their primary Spreadsheet as a “Test” and create our initial connection there. Once it’s been fully tested by Clearview and the Customer we set up the incoming Query connections to the recently rolled forward Spreadsheet to complete the build. When making changes to Documents, Spreadsheets, etc. we typically do this in copies of files versus entirely separate Workspaces. All of this being said, this is what's worked for us but I'm interested in other customers' perspectives as well!
0Zaloguj się, aby dodać komentarz.
Komentarze
Komentarze: 1