Re: [Archivesspace_Users_Group] Working with multiple ASpace strings
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 Sent: Thursday, May 30, 2019 8:32 AM To: Archivesspace Users Group 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: mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>> on behalf of "Joshua D. Shaw" mailto:joshua.d.s...@dartmouth.edu>> Reply-To: Archivesspace Group mailto:archivesspace_users_group@lyralists.lyrasis.org>> Date: Thursday, May 30, 2019 at 6:12 AM To: Archivesspace Group mailto:archivesspace_users_group@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-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org> mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>> on behalf of Rees, John (NIH/NLM) [E] mailto:re...@mail.nlm.nih.gov>> Sent: Wednesday, May 29, 2019 11:43 AM To: archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@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 ___ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
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: on behalf of "Joshua D. Shaw" Reply-To: Archivesspace Group Date: Thursday, May 30, 2019 at 6:12 AM To: Archivesspace Group 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-boun...@lyralists.lyrasis.org on behalf of Rees, John (NIH/NLM) [E] Sent: Wednesday, May 29, 2019 11:43 AM To: archivesspace_users_group@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 ___ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
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-boun...@lyralists.lyrasis.org on behalf of Rees, John (NIH/NLM) [E] Sent: Wednesday, May 29, 2019 11:43 AM To: archivesspace_users_group@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 ___ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
[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 ___ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
