Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Yiannis Vavouranakis 38 posts 78 karma points
    Nov 08, 2023 @ 11:58
    Yiannis Vavouranakis
    0

    Newsletter studio export data (for source control)

    Hello.

    We are using Umbraco 10 and have installed Newsletter Studio.

    Our solution is heavily dependent on sending transactional emails programmatically (password reset, OTP for email validation, booking confirmations, to name a few).

    We are a team of 3 .NET developers, and we are using CI/CD to deploy to SIT/UAT/preproduction/live environments. It seems that the data is non exportable via uSync. I noticed in the documentation (https://www.newsletterstudio.org/documentation/package/10.0.0/develop/database-tables/) that you mention the list of tables created by the package.

    a. Is there a way to export/import data from/to these tables in a way that's similar to uSync? b. Are there other places in the database that we need to take care of during deployment?

  • Markus Johansson 1936 posts 5864 karma points MVP 2x c-trib
    Nov 08, 2023 @ 16:33
    Markus Johansson
    0

    Hi!

    a.

    I'm sorry, at the moment we do not have any providers for uSync. Not for Umbraco deploy either.

    I have felt the same pain myself so I have been thinking about how to approach this.

    My own approach at the moment is to manually replicate the templates needed in the environments.

    b.

    It's a little tricky and kind of a rabbit hole. I mean, you would probably not want to sync all campaigns from test up to QA/Prod - but maybe any transactional emails. But, would you want to override the content from test when uploading to Prod? Maybe the client made changes that it would overwrite.

    I guess that good candidates for this would be:

    • Workspace + Settings (probably different per environment)
    • Transactional templates (at least create if not already exist).
    • Campaigns (maybe)

    I might be missing something but these are the tables that I would point out as most important.

  • Yiannis Vavouranakis 38 posts 78 karma points
    Nov 16, 2023 @ 10:17
    Yiannis Vavouranakis
    0

    Hello Markus.

    Thanks for the reply.

    We'll probably go the "recreate everything" route for the higher environments. But for sharing the repo (including data) between the devs, I think we need to come up with something more "automatic".

    Based on your response, I understand that newsletter studio does not add anything else in the database, outside its own dedicated tables. Therefore I'm thinking of creating a process to pull out all the data from these tables and save as a sql script within the repo, complete with drop/create table statements, to run before pushing, then create another process to run said script after pulling.

    It's not a transparent solution for sharing newsletterstudio data between developers, but it might do the job. Does it sound to you like something that would work?

    Regards,

    Yiannis

  • Markus Johansson 1936 posts 5864 karma points MVP 2x c-trib
    Nov 16, 2023 @ 10:26
    Markus Johansson
    0

    Hi!

    I agree, I feel the pain myself and I have not really come to find a "great" solution.

    It sounds like your work-around would be good for development - we tend to share a common SQL-server when we work on sites but I also know many devs have their own local database. I think that this will work for you while waiting for a more sustainable solution.

    Putting the transactional e-mails in source code

    Using uSync or some custom way of serializing templates to avoid the dependency on uSync. This would more or less solve the problem during development but when the solution is live and regular editors start to change the content we'd end up with an interesting situation. What should happen when you push a new release? Should the content be overwritten? Or should we only set the content if the email does not already exist?

    I can also see that this can be configurable settings on how to treat the serialized templates in different situations.

    Let me ask some questions and bounce some ideas with you:

    1. Do you see this only needed for Transactional Email or do you see any use case for campaigns?

    1. Probably workspace settings would be good to be able to sync as well. Or to "move" them to appsettings.json to be able to use different depending on environment.

    2. In the future we want to add "blue prints" or "start templates" and I guess this can be serialized in the same way as well.

    4. What do you think about the "only create if doesn't exists"-approach? Or do you think that it would need to overwrite? Maybe a setting?

    Cheers!

    // m

Please Sign in or register to post replies

Write your reply to:

Draft