What's the best practice to reinstall (or upgrade) Umbraco when code is on source control?
Hello,
I build an Umbraco project using NuGet and then I committed to source repository using the standard umbraco .gitignore which excludes the SqlCe database.
If I cloned the repository no re-installation happens.
To make it happen I emptied the umbracoConfigurationStatus value and I also clear the db connection string.
But this seems a bit complicate to do every time someone checks out the project for the first time. Also, how does it work I upgrade to a new version, push to the repository? How does other people get the upgrade if it involves changes in the DB?
Also, is this the best way to share code on git? or should I have included the db as well?
Send the new developer a backup of the database to restore locally once they've cloned the source code (and ongoing devs will need to communicate to share updates to doc types etc, - perhaps with the help of the uSync package)
Set up a centralised database on a shared server that they can point their connection string at (so all devs share the same database)
If not in contact with the other developers (perhaps for an open source example), include a script to create the database in source control
In terms of updates to Umbraco itself, that should work out OK whichever one of these options you use. On pulling the latest code, building and running Umbraco, if the database being used isn't up to date the installer should kick in.
For cloning repositories and getting Umbraco installed, you can copy the logic that we use in the Umbraco Core ... since it's exactly the same principle. We don't check in web.config, but we do check in web.Template.config - you can see the checked in files here: https://github.com/umbraco/Umbraco-CMS/tree/dev-v7/src/Umbraco.Web.UI
Then on build, the web.config is created based on the template and depending on the build environment it is transformed based on the debug/release config transform files. You can see how this is done here: https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web.UI/Umbraco.Web.UI.csproj#L2434 It's worth noting that we do not check in web.config, but it is included in the csproj.
So when a person checks out the project for the first time, they hit F5, the web.config is generated and the installer starts. We've been working like this for many years now and it works perfectly.
Regarding Courier - Courier can create 'Revisions' which you can do in the Courier section of the back office. You can select any type of Umbraco data and include it in the revision. My advise would be to create a 'Schema' one and then create a 'Starter Content' one. So you could install the Schema separately from the content if you wanted to. When you create a revision, it creates a snapshot of your data and persists it to files - which you can commit to Git. When you want to restore this Revision, you select it in the Courier section of the back office and install it.
The only problem with using this approach is that you will need to manually save these revisions when you change items but that is really just a button click (unless you've created new elements that you want to include in the revision, you'd need to select those). I'm sure it's possible to create event handlers for Umbraco services to auto-save/generate a revision - I've never done this but it should be possible if you wanted to try to automate this.
This is essentially what UaaS does too, however it has additional logic in place which automates much of this process and deals with revisions in a different way, however the underlying logic to create the revisions, etc... is just using the Courier APIs.
The next hurdle would be that when a developer clones the project and presses F5 to run the installer, they will still not have Courier installed - so they'd have to install this via the back office but it's pretty easy/fast to install a package.
The uSync method is very similar to what shannon says.
if uSync is installed via nuget then it will be included when the dev gets the solution.
Using a web.conifg transform is the best way - but you can blank the version number, from app settings, (and remove the UmbracoDSN) and that will kick off the install process.
depending on DB you can also use Chauffeur to setup the DB (this might be SQLCE only, I can't recall) but with that installed, a new dev can get the solution build the project and run
Chauffeur.Runner Install from the command line (in the bin folder) and that will setup the DB.
on first run (after install - either way) uSync will take everything from disk and apply it to the installation so you should get a complete site.
uSync will track changes you make, and if you souce control the usync/data folder then your changes should sync between all your devs.
uSync.Content Edition will do content if you want to do that too. It just adds content and media syncing to uSync.
If you want to do a more 'revisiony' way, then uSync.Snapshots can do that.
You can create a snapshot in time and get a folder with all the changes made since the last one. this is more manual - i prefer to just let source control do what it does and track changes in the usync files.
& Nuget all the things then on first build the dev gets all the packages they need.
What's the best practice to reinstall (or upgrade) Umbraco when code is on source control?
Hello, I build an Umbraco project using NuGet and then I committed to source repository using the standard umbraco
.gitignorewhich excludes the SqlCe database.If I cloned the repository no re-installation happens. To make it happen I emptied the
umbracoConfigurationStatusvalue and I also clear the db connection string.But this seems a bit complicate to do every time someone checks out the project for the first time. Also, how does it work I upgrade to a new version, push to the repository? How does other people get the upgrade if it involves changes in the DB?
Also, is this the best way to share code on git? or should I have included the db as well?
Simone
Hi Simone
Our usual approach would be one of three things:
In terms of updates to Umbraco itself, that should work out OK whichever one of these options you use. On pulling the latest code, building and running Umbraco, if the database being used isn't up to date the installer should kick in.
UaaS is another option to consider of course.
Hope that helps
Andy
I don't like any of the solutions... I want to version document types, not keep them in the database.
UaaS would be the best solution, but I cannot use it... but I'd like the same experience on premises
Comment author was deleted
have you seen https://our.umbraco.org/projects/developer-tools/usync/ ?
Hi Simone,
You could have a look at uSync. This is a great plugin for Umbraco that extracts document types to flat files which can then be source controlled.
There is also a uSync content edition that apparently does content although I've not tried this one.
Thanks,
Nik
Actually I was hoping Courier worked the same way :)
I'll try uSync indeed
I know Courier is meant to do content, I don't actually know if it does things like doc types as well. Could be worth a trial, I've never used it.
Hi all,
For cloning repositories and getting Umbraco installed, you can copy the logic that we use in the Umbraco Core ... since it's exactly the same principle. We don't check in web.config, but we do check in web.Template.config - you can see the checked in files here: https://github.com/umbraco/Umbraco-CMS/tree/dev-v7/src/Umbraco.Web.UI
Then on build, the web.config is created based on the template and depending on the build environment it is transformed based on the debug/release config transform files. You can see how this is done here: https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web.UI/Umbraco.Web.UI.csproj#L2434 It's worth noting that we do not check in web.config, but it is included in the csproj.
So when a person checks out the project for the first time, they hit F5, the web.config is generated and the installer starts. We've been working like this for many years now and it works perfectly.
Regarding Courier - Courier can create 'Revisions' which you can do in the Courier section of the back office. You can select any type of Umbraco data and include it in the revision. My advise would be to create a 'Schema' one and then create a 'Starter Content' one. So you could install the Schema separately from the content if you wanted to. When you create a revision, it creates a snapshot of your data and persists it to files - which you can commit to Git. When you want to restore this Revision, you select it in the Courier section of the back office and install it.
The only problem with using this approach is that you will need to manually save these revisions when you change items but that is really just a button click (unless you've created new elements that you want to include in the revision, you'd need to select those). I'm sure it's possible to create event handlers for Umbraco services to auto-save/generate a revision - I've never done this but it should be possible if you wanted to try to automate this.
This is essentially what UaaS does too, however it has additional logic in place which automates much of this process and deals with revisions in a different way, however the underlying logic to create the revisions, etc... is just using the Courier APIs.
The next hurdle would be that when a developer clones the project and presses F5 to run the installer, they will still not have Courier installed - so they'd have to install this via the back office but it's pretty easy/fast to install a package.
Hope that helps
Hi
The uSync method is very similar to what shannon says.
if uSync is installed via nuget then it will be included when the dev gets the solution.
Using a web.conifg transform is the best way - but you can blank the version number, from app settings, (and remove the UmbracoDSN) and that will kick off the install process.
depending on DB you can also use Chauffeur to setup the DB (this might be SQLCE only, I can't recall) but with that installed, a new dev can get the solution build the project and run
Chauffeur.Runner Installfrom the command line (in the bin folder) and that will setup the DB.on first run (after install - either way) uSync will take everything from disk and apply it to the installation so you should get a complete site.
uSync will track changes you make, and if you souce control the
usync/datafolder then your changes should sync between all your devs.uSync.Content Edition will do content if you want to do that too. It just adds content and media syncing to uSync.
If you want to do a more 'revisiony' way, then uSync.Snapshots can do that.
You can create a snapshot in time and get a folder with all the changes made since the last one. this is more manual - i prefer to just let source control do what it does and track changes in the usync files.
& Nuget all the things then on first build the dev gets all the packages they need.
is working on a reply...