[Archivesspace_Users_Group] Working with multiple ASpace strings

[Rees, John (NIH/NLM) [E]]

Thank you.

As usual, it’s the nervous-human equation that is the most confounding when embarking on major technological change.

Namaste,
John


From: Kevin Clair <Kevin.Clair at du.edu>
Sent: Thursday, May 30, 2019 8:32 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Working with multiple ASpace strings

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<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of "Joshua D. Shaw" <Joshua.D.Shaw at dartmouth.edu<mailto:Joshua.D.Shaw at dartmouth.edu>>
Reply-To: Archivesspace Group <archivesspace_users_group at lyralists.lyrasis.org<mailto: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<mailto: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!
Joshua

________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Rees, John (NIH/NLM) [E] <reesj at mail.nlm.nih.gov<mailto:reesj at mail.nlm.nih.gov>>
Sent: Wednesday, May 29, 2019 11:43 AM
To: archivesspace_users_group at lyralists.lyrasis.org<mailto: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





John P. Rees

Archivist and Digital Resources Manager

History of Medicine Division

National Library of Medicine

301-827-4510










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190530/14cce1db/attachment.html>