[Archivesspace_Users_Group] Working with multiple ASpace strings

Joshua D. Shaw Joshua.D.Shaw at dartmouth.edu
Thu May 30 08:12:14 EDT 2019

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

Hi all,

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...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190530/4fc69bbd/attachment.html>

More information about the Archivesspace_Users_Group mailing list