Copied to clipboard

Flag this post as spam?

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


  • Ken Burcham 9 posts 99 karma points c-trib
    Aug 11, 2020 @ 15:27
    Ken Burcham
    0

    Dev and production workflow - how to move new Document Types to dev?

    Hi!

    I'm just building my first production Umbraco site and am realizing I need to know how to manage some of the Umbraco magic.

    We haven't yet moved the site into production, but I have a demo site we're building up with several editors working to add content. I also work in the demo site to build out new Document Types, etc. I'm using visual studio in my dev environment, but just to push template changes and new core functionality changes. I use the visual studio "publish" feature to copy the templates and occasional builds to the demo site.

    I just noticed that when I make new Document Types, they are in the demo site but obviously not in my dev.

    So here is my question: What all do I need to copy from my demo site back to my production site to get the new Doc Types? Just the AppData\packages and AppData\Models folders? Or is it more complicated than that? If I do a full build and publish, I'll overwrite my newly created Document Types...

    Or maybe the question is: How should I setup my workflow so that my editors can continue making changes to content and I can make changes to the settings and configuration?

    I'd love being pointed to documentation, but haven't been able to find any yet...

    Thank you!

  • Simon Ulmbrant 34 posts 154 karma points
    Aug 11, 2020 @ 16:00
    Simon Ulmbrant
    0

    In many projects I've been developing I have used uSync. usync do exactly what you want almost. It serializes the settings, doc types and even content if you want, outputs it to a data folder which you then can copy to your other sites and import. In the latest project I'm in now we have added the data folder to the deploy flow and doing imports on while loading the site. More or less automatically

  • kleptbit 42 posts 98 karma points
    Aug 13, 2020 @ 10:50
    kleptbit
    0

    I think you need this documentation - migrating an existing site to the cloud - you need to deploy the metadata via Git:

    https://our.umbraco.com/documentation/Umbraco-Cloud/Getting-started/migrate-existing-site/Migrate Existing site

  • Sotiris Filippidis 276 posts 1433 karma points
    Aug 15, 2020 @ 16:31
    Sotiris Filippidis
    100

    You are right to be confused here - let's clear this up by seeing what gets published via Visual Studio for Umbraco.

    Templates, views, assets (css/js/maybe some images) - everything belonging to your project will be published as expected.

    Document types, data types, dictionary items - these will not get published. These do not correspond to files in your project but are rather set up in the Umbraco database. The appdata\models folder contains code files that correspond to your doctypes (assuming you're using Models Builder), so that you can refer to your doc properties in a strongly typed manner, but are not used to construct the document types and data types themselves.

    So what previous responses really say is that you either need to use a third party tool (in this case, uSync), or move to Umbraco Cloud which does this work for you when deploying between environments.

    uSync generates files that can then be part of the publishing process and be copied to wherever you publish the site to - you have to have uSync on both environments and configure it so that it generates (serializes) any change on your source (local, in this case) environment. On the other side (your dev environment) you can configure it to either automatically apply changes or let you manually apply them. uSync will do what Visual Studio publish won't - apply changes and generate new doctypes and custom data types (and dictionary entries, if you want).

    Another way to sync structure changes to another environment would be to create a package containing the items you have changed and upload it and install it to your other environment. This can prove useful if changes are rare and simple, but things can really get out of hand if changes take place often and the volume of changes is large - mainly because you may at some point forget to add something to the package.

    In all cases, we're talking structure, not data - in order to sync data you need yet another third party tool (usync content edition).

  • Ken Burcham 9 posts 99 karma points c-trib
    Aug 24, 2020 @ 17:38
    Ken Burcham
    0

    Thank you for giving me the background and helpful information! (and to the others who responded as well)

    My situation is that my dev server is not local (due to IT restrictions). I work local in VS and then "publish" my changes to the dev server by manually copying just the bin files (as needed), views, and css. When I create new Document Types, I have to manually copy the generated models back from the dev server to my local VS.

    This seems to be working.

    However, soon I'll be setting up a production server where content is continually updated. I guess the best practice would be to never create new Document Types on the production server or even make small tweaks to existing DT's. Document Type management should only be done in development? Then it sounds like I can use uSync to copy the new DT's to the production server.

    Does that seem like the right approach?

    Thank you!

Please Sign in or register to post replies

Write your reply to:

Draft