When we’re developing for Umbraco, we use SQL Local DB as the database and uSync for persisting changes to source control (Azure DevOps). We use GitFlow in most cases when it comes to branching.
This works really well, but the main issue is that the local database never gets deleted and that has some consequences:
When you clean up uSync, you commit a clean uSync to source control, but the next user that works on it with an existing database might clutter uSync again.
When you start working on a new feature and you need to revise a previous feature (for instance to correct something based on comments in a PR), you could add things to uSync that are releated to the new feature to the old feature because things from the new feature are still present in the local database.
Sometimes you don’t notice that uSync is really broken. When working on existing databases, it keeps working fine. But when someone wants to work on the project for the first time and doesn’t have a database, that’s the moment you notice that uSync will not import because of issues or conflicts that users with an existing database simply don’t see.
So my solution would be to just delete the local DB on branch switch and this will solve the issues. But this doesn’t seem to be really trivial. Visual Studio does not have like a branch switch event. How would I do this?
Or perhaps there is an other solution than to just delete the database. I’m curious how you all handle this.
To run actions after switching branches in Git, use the post-checkout hook within the .git/hooks directory. This hook is triggered after a successful git checkout or git switch command, and receives parameters about the previous and new HEADs, as well as whether the checkout was a branch switch. You can use this hook to execute scripts or commands that need to run after a branch change.
not used this specifically.. but do use the git-commit hook to ensure the commit message includes the branch name…
And not really a repo option, more a when setting up your clone do this step?
Also not all git clients supported (github desktop in particular didn’t) this when I last tried.. but sourcetree is one that does.
copilot says..
#!/bin/sh
# Delete all .sdf files in src/umbraco/data/
rm -f src/umbraco/data/*.sdf
# Clean up untracked files
git clean -fd
# Optional: Remove ignored files
git clean -fdX
# Optional: Remove ALL untracked files, including ignored ones
git clean -fdx
Also presume you are using Unattended appsettings to install a local db if none currently exists..
There is also uSYnc firstboot, that may be of use? FirstBoot | Jumoo docs
And Usync.Stop Usync.Once to only do the usync importatstartup once.
And maybe usync snapshots that could be linked to branches for a start point to import?
This was the direction I saw and seems to have the best promise since it can be added to source control easily. Added bonus is that it’s IDE agnostic
We ofcourse have unattended install configured, so the database will be created when it doesn’t exist. Deleting the database would work well since it would just create the database on boot AND run uSync at startup so you get a nice filled environment.
uSync first boot doesn’t work I think for us. Right now we import at startup. The drawback is that the import is done at EVERY startup, which means a local development environment boot slower than it otherwise would. It seem to make sense to use first boot if you delete the database on every branch change, BUT if you merge an other branch in the local branch, the database would not get deleted and you would need to manually run uSync to get all the latest into Umbraco. And I think a lot of developers would forget that…
It’s mostly a procedural thing. When developing, you always want to make sure that you have the latest situation, so currently we run a full import on every boot. In development environments, there is not that much content (and it’s more about the content types, data types etc anyway), so it doesn’t slow booting too much.
In this topic, I talked about deleting the database on branch change. In that case the ‘first boot’ option might make sense to speed up development boot times. Since the database is deleted on branch change, you always know you have the correct database when uSync has loaded on first boot and it might speed up development.
However, there is one situation the might cause an issue: when I merge the develop branch in a feature branch and uSync is set to only run on first boot, I might forget to import the changes that come from the develop branch. So it’s safer to just always import on boot just to be sure.
We’re going to evaluate our way of working and how to use uSync better in development (content gets a complete mess after some time) soon, I’ll post the results here
I wonder if there is some combination of Usync import on startup and the uSync.Once/Stop file that could work here..
maybe a git merge hook .. to rename uSync.Stop to uSync.Once in the feature branch if merging develop or even any merge..
Though we just have import on startup for settings only for development and remote environments, (leaving content mutually exclusive between environments, purely for to avoid and headaches from client content editing) and it’s not a big overhead..
We use the uSync.Once/Stop approach for only importOnStartup when deploying - (powershell in the CI/CD process)
Then if you need to develop against a certain piece of content depending on how destructive you might be you can either
work directly against a remote database,
fetch down the staging/uat/qa/prod database locally and work against that.
temporarily set tracking of content on the remote environment and generate your uSync Content configs to import to local..
uSync.Complete to push/pull content around environments.
(a nightly backup of databases can also ease the pain, for quick retrieve and local
restore)
this writes the latest commit to disk every time you import (it foes into usync/git.meta, that file shouldn’t then be tracked by git)
then on startup, it checks git locally to see if there are any untracked things (e.g is the repo dirty) if its clean it then compares the latest commit in the git to the one on disk for the last import.
if they are different it runs an import.
this would mean imports run when you pull your repo down and run things.
it wouldn’t run an import when,
1). the local repo has any pending changes.
2) the last sync matches the last commit.
this could be extended to do other things - react to only merges track file changes in uSync folders etc.
Just thinking in code really - but interested to know if this type of thing would help.
| Jumoo docs
