[Archivesspace_Users_Group] Working with multiple ASpace strings
Kevin.Clair at du.edu
Thu May 30 08:32:22 EDT 2019
At Denver we have one less environment than Dartmouth, and our ArchivesSpace is hosted so our development environment tends to only gets its data synced with production when new releases come out, but otherwise we do what Joshua does. -k
From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of "Joshua D. Shaw" <Joshua.D.Shaw at dartmouth.edu>
Reply-To: Archivesspace Group <archivesspace_users_group at lyralists.lyrasis.org>
Date: Thursday, May 30, 2019 at 6:12 AM
To: Archivesspace Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Working with multiple ASpace strings
We've got three (well four if you count my local dev) environments and follow a pretty strict process of data always goes from prod -> other environments via a db clone and code always pushes up via local->dev->pre-prod->prod with varying degrees of QA along the way. We also QA integrations the same way. I typically clone the production data before any QA process to ensure that the QA environment is as close to prod as possible. Long story short... we follow a hybrid of #1 & #3. Tests of code changes & representative data in QA and then full runs in production.
Hope that helps!
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Rees, John (NIH/NLM) [E] <reesj at mail.nlm.nih.gov>
Sent: Wednesday, May 29, 2019 11:43 AM
To: archivesspace_users_group at lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Working with multiple ASpace strings
This question isn’t aspace-centric, but for those of you that have multiple deployment strings (dev, qa, production) and that use the PUI, what is your best practice for entering new data or massaging existing data?
1. Do you test load/edit in QA then re-run the job in production?
2. Or do you load/edit in QA and replicate/auto-deploy to production? Can you just copy the database and re-index?
3. Not agonize over mistakes and just do it all in production?
4. Something else?
Do you worry about keeping the strings in synch?
Our old process was like #1, but we had separate systems for generating EAD and public facing search/discovery. With Aspace we are adding additional customers, more data types, less user command/control, etc. Is there a sweet spot for ensuring data integrity but have non-burdensome and flexible workflows?
John P. Rees
Archivist and Digital Resources Manager
History of Medicine Division
National Library of Medicine
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Archivesspace_Users_Group