Are there any good docs on best practice for working in teams to develop Umbraco sites? Specifically I'd like to know the best way to keep databases in sync across multiple locally working developers. We have the code in Git but each time a doc type is changed we need to sync local DBs. Courier is one option but the local sites are not easily accessible to one another and I am having difficulty transferring non-standard datatypes with Courier.
That's an excellent idea for an article. I'll see if I can put something together in the coming weeks.
Until then, I typically just create a DB in a shared server that all the devs can access. uSync is also an option, but there are some pitfalls you'll come across; all solvable problems, and I'm sure it's improved since I last used it months (or was it years) ago. See here: https://our.umbraco.org/projects/developer-tools/usync/
Not sure what you mean by having the gitignore replicate things. Typically, you'd use the gitignore to ensure things don't get replicated (i.e., committed and pulled down to another computer).
I don't use the Umbraco Grid editor (I mainly use Archetype). However, I don't see why you couldn't commit the grid files to the repo and have the other developers pull that down. I tend to exclude DLL's from the repo, unless they aren't available via NuGet, in which case I create a lib folder to store the DLL's and I reference them from my project(s).
Another strategy I tend to follow is to create most of the data types all in one go in advance of development starting (Archetype makes this super easy). I add more and make some modifications here and there, but getting it mostly done makes things go more smoothly (helps keep everybody on the same page).
Try to avoid the lib folder though, it's pretty easy to package up libraries in a nupkg and put them on a MyGet feed so you can restore them from anywhere (local/build server, etc.).
That sounds interesting. I sometimes create a local NuGet feed from the file system, which is removes the value of NuGet for the most part. And I wasn't able to share that among team members.
Would MyGet allow me to host binaries so that they can be added to projects with NuGet and it would just work during NuGet package restore when somebody builds?
Twitter is very restrictive, I tried there not knowing this conversation originally started here, but Nicholas let me know and here I am :)
Apart from the database, there are various scenarios where the team is going to need to share the same set of files, be it media files or other stuff. So far my preferred approach is to have a common database, git for everything code-related, and BTSync in case we need to sync media and/or other files that don't need to be in source control. BTSync has its own pitfalls, but if you are cautious it's pretty safe.
Regarding the database, and specifically the scenario where each dev works with a different DB, I'm still curious as to what the best solution is. In order to sync different copies I've considered RedGate software (or similar software), Courier, uSync, but nothing seems to be able to do the complete job - at least not easily. This is due to the fact that the db holds both some configuration information (template names, macro parameters etc.) as well as data, and sometimes you just need to sync configuration, sometimes data, sometimes both.
When developing custom software, it's easy - especially if you have a database with a non-stable schema. You create versions for your DB (even a table with version history would do) and scripts to bring it up to the latest version. You can even tie your scripts with your source control versions or tag so that you know what scripts you have to run to bring your db to a specific version. Data can follow as scripts, too.
With Umbraco, of course, this is not the case. You have a pretty standard schema, but the data inside the db represent different things, and only some of the data are actually data.
(Just thinking aloud here, sorry.)
I think that, when developing with different DBs, we should just stick with conventions. Whenever a change occurs, devs should need to install a specifically created package (and update it with new versions) which would bring things up to date, and this package could be on source control too. This could well contain configuration and data, but only things database-related (document types, macros, dictionary entries - not files that are already on source control).
Adding to that thought, a system to check if Umbraco has the latest "update package" version could also prove useful.
uSync was built to address the shared database development issues - it syncs all of the configuration bits that are stored in the db, and if you combine that with the files that aren't in the db (such as css, and views) then you should have the shared environment your looking for.
If you have tried usync and had problems i am really open to any feedback you may have, I always looking to make it work better for people.
I haven't really tried uSync although I have read the description in the past and think of it as the most appropriate way of syncing things when using a different db per developer. It would be nice if there was an auto-import feature though, so that devs don't forget to import things.
What I mentioned in case you accidentally misread (it's easy to misread this, I've been there more than once :) ) was BTSync (BitTorrentSync) - as a way to keep filesystem changes synced.
EDIT - I just realized that there is uSync Snapshots which does exactly what I was referring to - I'll be sure to give it a try!
yeah no worries. uSync does do auto import by default (that is it will import changes when ever a site starts) - do give it a go and if there are any issues fire them into the usync forum.
I'll just jot down some ideas for myself before I forget.
Archetype. When creating data types using this tool, it's relatively easy to copy between environments (e.g., dev/stage/prod), as the entire configuration can be copied as a JSON string and pasted into other environments (sometimes requires other modifications after pasting).
Multi-step deployments. When deploying multiple things, I can be useful to deploy the things that aren't destructive (e.g., new data types and doctypes), then deploy the code, then do things that are destructive (e.g., delete properties from doctypes).
Will have to consider those further. Not sure if they're really tied to teams or if they're just things to do in general.
Time goes by and there are many tools helping us with this process now.
From my perspective the most helpful are:
shared DEV database
source control + CI/DP (TeamCity, AppVeyor) process with properly configured builds
keeping media on Azure blobs (or other containers like OpenStack for example) to avoid a need to have them inside source control and moving across developers
uSync (as mentioned earlier) is helping to not only avoid sharing a db, but also to have changes made in document types and other objects inside source control
nuget everything! You can create your own nugets with packages / functionalities / micro-services and it's a lot easier to just update-package or restore it than handling a lot of changes in source control in DB (especially working with packages and fortunately, I know that we (developers, ASP.NET "vNext", Umbraco "vNext") are going in this direction!!
When you are talking about developing Umbraco sites in teams, you should have a look at Umbraco as a Service.
This is one of the challenges that we solve with Umbraco as a Service, it´s easy to add and remove team members to your projects, you will get automated patch upgrades, to ensure that you are running on the latest patch release of Umbraco.
Another great thing with Umbraco as a Service is that you are getting easy deployment between the different environments.
Developing Umbraco sites in teams
Hi
Are there any good docs on best practice for working in teams to develop Umbraco sites? Specifically I'd like to know the best way to keep databases in sync across multiple locally working developers. We have the code in Git but each time a doc type is changed we need to sync local DBs. Courier is one option but the local sites are not easily accessible to one another and I am having difficulty transferring non-standard datatypes with Courier.
Thanks
That's an excellent idea for an article. I'll see if I can put something together in the coming weeks.
Until then, I typically just create a DB in a shared server that all the devs can access. uSync is also an option, but there are some pitfalls you'll come across; all solvable problems, and I'm sure it's improved since I last used it months (or was it years) ago. See here: https://our.umbraco.org/projects/developer-tools/usync/
Thanks for your input!
We've tried the shared DB route but it's not working very well. I'm not sure why. I think things like the grid editor save data to the file system.
I guess we need a .gitignore file that replicates pretty much everything - including DLLs?
Not sure what you mean by having the gitignore replicate things. Typically, you'd use the gitignore to ensure things don't get replicated (i.e., committed and pulled down to another computer).
I don't use the Umbraco Grid editor (I mainly use Archetype). However, I don't see why you couldn't commit the grid files to the repo and have the other developers pull that down. I tend to exclude DLL's from the repo, unless they aren't available via NuGet, in which case I create a
libfolder to store the DLL's and I reference them from my project(s).Another strategy I tend to follow is to create most of the data types all in one go in advance of development starting (Archetype makes this super easy). I add more and make some modifications here and there, but getting it mostly done makes things go more smoothly (helps keep everybody on the same page).
Try to avoid the
libfolder though, it's pretty easy to package up libraries in a nupkg and put them on a MyGet feed so you can restore them from anywhere (local/build server, etc.).That sounds interesting. I sometimes create a local NuGet feed from the file system, which is removes the value of NuGet for the most part. And I wasn't able to share that among team members.
Would MyGet allow me to host binaries so that they can be added to projects with NuGet and it would just work during NuGet package restore when somebody builds?
That's what MyGet was made for! Just need to add the package source to the nuget.config file in the root of your solution.
Thanks for the tip! I gave it a try today and it worked nicely. Will have to start doing that going forward.
Hi Nicholas
Sorry for delayed reply!
I meant strip out the gitignore so all code is staged in Git and shared across developers.
Datatypes in advance is what I try to do also but then a new page comes along, or a site refresh and things need changing regularly.
FYI, a Twitter discussion has been started in preparation for the article: https://twitter.com/MrMarsRed/status/732053985440358400
Twitter is very restrictive, I tried there not knowing this conversation originally started here, but Nicholas let me know and here I am :)
Apart from the database, there are various scenarios where the team is going to need to share the same set of files, be it media files or other stuff. So far my preferred approach is to have a common database, git for everything code-related, and BTSync in case we need to sync media and/or other files that don't need to be in source control. BTSync has its own pitfalls, but if you are cautious it's pretty safe.
Regarding the database, and specifically the scenario where each dev works with a different DB, I'm still curious as to what the best solution is. In order to sync different copies I've considered RedGate software (or similar software), Courier, uSync, but nothing seems to be able to do the complete job - at least not easily. This is due to the fact that the db holds both some configuration information (template names, macro parameters etc.) as well as data, and sometimes you just need to sync configuration, sometimes data, sometimes both.
When developing custom software, it's easy - especially if you have a database with a non-stable schema. You create versions for your DB (even a table with version history would do) and scripts to bring it up to the latest version. You can even tie your scripts with your source control versions or tag so that you know what scripts you have to run to bring your db to a specific version. Data can follow as scripts, too.
With Umbraco, of course, this is not the case. You have a pretty standard schema, but the data inside the db represent different things, and only some of the data are actually data.
(Just thinking aloud here, sorry.)
I think that, when developing with different DBs, we should just stick with conventions. Whenever a change occurs, devs should need to install a specifically created package (and update it with new versions) which would bring things up to date, and this package could be on source control too. This could well contain configuration and data, but only things database-related (document types, macros, dictionary entries - not files that are already on source control).
Adding to that thought, a system to check if Umbraco has the latest "update package" version could also prove useful.
Hi
uSync was built to address the shared database development issues - it syncs all of the configuration bits that are stored in the db, and if you combine that with the files that aren't in the db (such as css, and views) then you should have the shared environment your looking for.
If you have tried usync and had problems i am really open to any feedback you may have, I always looking to make it work better for people.
Kevin,
I haven't really tried uSync although I have read the description in the past and think of it as the most appropriate way of syncing things when using a different db per developer. It would be nice if there was an auto-import feature though, so that devs don't forget to import things.
What I mentioned in case you accidentally misread (it's easy to misread this, I've been there more than once :) ) was BTSync (BitTorrentSync) - as a way to keep filesystem changes synced.
EDIT - I just realized that there is uSync Snapshots which does exactly what I was referring to - I'll be sure to give it a try!
yeah no worries. uSync does do auto import by default (that is it will import changes when ever a site starts) - do give it a go and if there are any issues fire them into the usync forum.
I'll just jot down some ideas for myself before I forget.
Archetype. When creating data types using this tool, it's relatively easy to copy between environments (e.g., dev/stage/prod), as the entire configuration can be copied as a JSON string and pasted into other environments (sometimes requires other modifications after pasting).
Multi-step deployments. When deploying multiple things, I can be useful to deploy the things that aren't destructive (e.g., new data types and doctypes), then deploy the code, then do things that are destructive (e.g., delete properties from doctypes).
Will have to consider those further. Not sure if they're really tied to teams or if they're just things to do in general.
There was a presentation performed by Janusz Stabik during Umbraco UK Festival 2015: https://www.youtube.com/watch?v=Jw_wzVbfRSM about this specific topic. Worth to check.
Time goes by and there are many tools helping us with this process now.
From my perspective the most helpful are:
Thanks for the video! Some excellent ideas #h5yr
Hi Dan,
When you are talking about developing Umbraco sites in teams, you should have a look at Umbraco as a Service.
This is one of the challenges that we solve with Umbraco as a Service, it´s easy to add and remove team members to your projects, you will get automated patch upgrades, to ensure that you are running on the latest patch release of Umbraco.
Another great thing with Umbraco as a Service is that you are getting easy deployment between the different environments.
You can find more about Umbraco as a Service here. http://umbraco.com/cloud
Best,
/Dennis
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.