All is fine and well while we develop locally but how best to get all our mods, code and templates into SVN so they don't get lost. Alot of the content is stored in the DB and when you modify a doc type how to you save that so another developer can recreate it easily? Do we go the Rails route of dumping out the schema? Had an idea to have the commit hook run a schema dump on every check in but that might be over kill.
Anyone else run into the same problems and how did you handle it?
I'd be interested in this too, with nearly all assets requiring a database entry it seems quite awkward to do successfully. I'd love to see a how-to guide from anyone who's got a SVN setup they're happy with.
Your other point has been discussed at length here.
Thanks for the link Rick I'll add it to my other question for reference.
Also we are looking for interest in a M62 meet up if you fancy it? See the meet up forum and add your name to the list. It will be mainly beer, umbraco and salty snack based :)
Where the actual website is in the Web folder (This is not under SVN and is not part of the solution either), then all client specific templates, css, macros etc are within the Client.Web project. We then use a post build script to copy the resources to the web folder. You can use the CMS to create things like templartes etc, but then we just copy it to the Client.Web project and modify it there instead. We also use a configmerging tool to merge none standard config settings in to the different config files (this works great as we just keep the differences in our configs, rather than maintaining full configurations). Basicaly, it should be possible to create a Web folder with a raw Umbraco site, then use the post build event to copy over all the client settings. The only thing I haven't quite worked out yet, is third party packages.
In terms of the databse, we have a shared developer database which all developers connect to. When merging with the live, we currently take a copy of the live database and then use a database diff tool (Try xSQL - Free for SQL Express databases).
It is the databases that I find the most dificuilt to merge aswell, as changes to templates etc can just be uploaded.
If you don't mind spending a bit of money, you could buy a pro license which gives you courier and concierge which help with that sort of thing.
Just as an idea, I was wondering if you could use the inbuilt replication feature to copy any live changes to a test ennvironment. I've not tried this, nor really thought it through, so don't burn me if you think is dumb =)
Pro is not an option in this case as its just a little site for a friend while I learned Umbraco, plus £650 for each site is going to really hurt the bottom line.
A schema dump might be the way to go then. I don't like the fact you have to manually merge the DB each time.
Maybe another way is to create a package when you are ready to wrap up a bit of functionality and SVN the package? Not played with Packages much though so need to read up on them to see whats possible.
How the heck do you tag a website thats mostly in a DB...I'll keep playing :)
My trouble is I don't want to have to rebuild the solution every time, its slow, I like hacking my XSL in a vanilla text editor (Textpad), save, refresh. That works. I think you'd only need a schema dump when you check in a block of code assuming you've made any changes to the DB that is, hmm wonder how you could check against that? Could keep a record of the latest ids for the various tables? If they have changed then the DB is dirty and needs a schema dump?
The post build stuff is good if you are doing .net goodness but you can also mess with the DB via the UI so no build would run and no schema generated.
Been playing with backups in SQL and restoring them, assume there is a command line option, might have to have a play around.
Checked out packages and not all that impressed, far to manual for what we are looking for I think. Fine for a one of fix/patch but not ideal for regular updates or source control.
I was about to ask a question along the lines of this topic and found this :)
We currently have 3 developers working on an Umbraco project - similar to the structure above we have a web application project that contains all new / edited files (mirroring the Umbraco folder structure) and a separate web root folder that contains the Umbraco installation. When we build, xcopy commands copy all files across to the web root - this allows each developer to have their own installation of Umbraco which is then over written by the custom stuff (including the web.config which points to a shared database).
I'm starting to look at how this is going to work for packages but hit a stumbling block - when a package is installed this will create the db entries (available to everyone) but the package files will only be created in the developers web root.
One idea I had was to create a copy of the web root pre package installation and use winmerge (or another similar tool) to highlight the differences between the two folders. These differences could then be stored under the relevant package folder in source control and copied across when built as per the custom stuff above..
I've been lazy with this of late. Umbraco is mostly frozen at 4.7 and the days of epic breaking changes are on hold until 5 comes out some time late next year. As a result I tend to stick the whole site in source control and not use the separate umbraco site pattern you mention above. This means you can branch it just like any other site if you wanted although again we've moved away from that quite a bit of late and prefer to have our sites releasable all the time rather than having several branches here and there. I'll have a parent folder with the umbraco site inside this as a child folder, then I'll add any custom C# goodies as another folder too and have a build event to copy over our DLL's to the umbraco bin folder on (successful) compile/unit test run. For ease we cheat and check in the last working version of any custom DLL's so that James (aka @welcomebrand) does not need to have visual studio running on his machine. Ideally I'd like him to pull these from our build machine once its build via a little script or something but you know what...it works for us as is so no need to worry about it yet. Simple solution is better than smartest most of the time it seems.
We all use a shared development DB and work off that. If we are installing a package then it is done as a atomic action. Meaning, clean synced up site, install package, test then commit and push. That way its all in one check in and not messing with anything else.
We have a ignore file that we use for Mercuiral/Kiln (which reminds me I really must share that) which makes what to put in source control much easier.
uSitebuilder is probably the best way to go for developers building a site and good source control, makes it next to impossible for your designers to help out though as you have to do all your doc type work via C# classes and not via the UI so its swings and round abouts. Its it is a site of any size I'd go with uSitebuilder now. Tiny sites just use the UI. We will be giving it a go on our AgenCMS site when we refactor it later in the year. Main advantage is that having commit messages for template mods is ok but there is no way to link those to DB mods that they might need to work, using uSitebuilder gives you those details. @Cultiv has had a lot of sucesse using Razor for with his setup like this too and says it works really well, no need for creating macros manually this way. That said I know @leekelleher has build a XSLT Provider which allows the same thing for XSLT macros now too. Might be worth taping him up for it.
This all works until you go live and then the lines blur quite a lot as to what you should do where, when and how. Courier 2 takes away a lot of the pain but we've not used it in anger yet mainly after talking it through with several of the build machine heavy hitters at CG11. The tool is amazing but to work well in a multi-developer environment it needs a strict workflow in place or you could really mess things up. It suffers from developers having to work on only one features/changeset at a time or you risk uploading half finished work (It works out dependancies for any file and will upload them all meaning some items could go up unfinished if you have multiple changes going on in one build). Again branching can help you here, only ever work on a feature in a branch and merge it into the main branch/trunk once ready for live. Another issues I believe exists with Courier is there is no roll back option that I know of I could be wrong there but I'm not aware of one (please feel free to correct me).
Ideally don't edit on live, content is fine but not templates, css, assets etc. once live then template updates etc. are all managed manually by source control on the servers.
The way we currently work in terms of making changes / adding new stuff is to create them via the Umbraco UI and then retrospectively copy them into the source controlled 'Custom' project.
What I may do is store the web root (i.e umbraco core plus any installed packages) in source control, but separate to the custom stuff.. I like the separation of custom development work (inc. css/scripts/templates) etc from the core - it's quite clean.
Best Practices - Umbraco, developing and source control
We use SVN here in the office but I'm struggling to get my head around how best to keep our Umbraco goodness in source control. This relates to my other question http://our.umbraco.org/forum/using/ui-questions/3323-Best-Practices---How-to-develop-once-site-is-live-
All is fine and well while we develop locally but how best to get all our mods, code and templates into SVN so they don't get lost. Alot of the content is stored in the DB and when you modify a doc type how to you save that so another developer can recreate it easily? Do we go the Rails route of dumping out the schema? Had an idea to have the commit hook run a schema dump on every check in but that might be over kill.
Anyone else run into the same problems and how did you handle it?
I'd be interested in this too, with nearly all assets requiring a database entry it seems quite awkward to do successfully. I'd love to see a how-to guide from anyone who's got a SVN setup they're happy with.
Your other point has been discussed at length here.
Thanks for the link Rick I'll add it to my other question for reference.
Also we are looking for interest in a M62 meet up if you fancy it? See the meet up forum and add your name to the list. It will be mainly beer, umbraco and salty snack based :)
We currently have a structure as follows:
Solution Folder
- Client.Web
- - Images
- - MasterPages
- - Css
- - Scripts
- - Xslt
- - UserControls
- Web
- Client.sln
Where the actual website is in the Web folder (This is not under SVN and is not part of the solution either), then all client specific templates, css, macros etc are within the Client.Web project. We then use a post build script to copy the resources to the web folder. You can use the CMS to create things like templartes etc, but then we just copy it to the Client.Web project and modify it there instead. We also use a configmerging tool to merge none standard config settings in to the different config files (this works great as we just keep the differences in our configs, rather than maintaining full configurations). Basicaly, it should be possible to create a Web folder with a raw Umbraco site, then use the post build event to copy over all the client settings. The only thing I haven't quite worked out yet, is third party packages.
In terms of the databse, we have a shared developer database which all developers connect to. When merging with the live, we currently take a copy of the live database and then use a database diff tool (Try xSQL - Free for SQL Express databases).
It is the databases that I find the most dificuilt to merge aswell, as changes to templates etc can just be uploaded.
If you don't mind spending a bit of money, you could buy a pro license which gives you courier and concierge which help with that sort of thing.
Many thanks
Matt
Just as an idea, I was wondering if you could use the inbuilt replication feature to copy any live changes to a test ennvironment. I've not tried this, nor really thought it through, so don't burn me if you think is dumb =)
Hehe ideas are good so keep them coming!
Pro is not an option in this case as its just a little site for a friend while I learned Umbraco, plus £650 for each site is going to really hurt the bottom line.
A schema dump might be the way to go then. I don't like the fact you have to manually merge the DB each time.
Maybe another way is to create a package when you are ready to wrap up a bit of functionality and SVN the package? Not played with Packages much though so need to read up on them to see whats possible.
How the heck do you tag a website thats mostly in a DB...I'll keep playing :)
I guess extending my method you could use something like SQL Database Publishing Wizard to create a scheme dump as a post build event?
You may want to create a specific build config so that you don't create one every time you build though.
What do you think?
My trouble is I don't want to have to rebuild the solution every time, its slow, I like hacking my XSL in a vanilla text editor (Textpad), save, refresh. That works. I think you'd only need a schema dump when you check in a block of code assuming you've made any changes to the DB that is, hmm wonder how you could check against that? Could keep a record of the latest ids for the various tables? If they have changed then the DB is dirty and needs a schema dump?
The post build stuff is good if you are doing .net goodness but you can also mess with the DB via the UI so no build would run and no schema generated.
Been playing with backups in SQL and restoring them, assume there is a command line option, might have to have a play around.
Checked out packages and not all that impressed, far to manual for what we are looking for I think. Fine for a one of fix/patch but not ideal for regular updates or source control.
Best put the thinking flat cap on...
Hi.
I was about to ask a question along the lines of this topic and found this :)
We currently have 3 developers working on an Umbraco project - similar to the structure above we have a web application project that contains all new / edited files (mirroring the Umbraco folder structure) and a separate web root folder that contains the Umbraco installation. When we build, xcopy commands copy all files across to the web root - this allows each developer to have their own installation of Umbraco which is then over written by the custom stuff (including the web.config which points to a shared database).
I'm starting to look at how this is going to work for packages but hit a stumbling block - when a package is installed this will create the db entries (available to everyone) but the package files will only be created in the developers web root.
One idea I had was to create a copy of the web root pre package installation and use winmerge (or another similar tool) to highlight the differences between the two folders. These differences could then be stored under the relevant package folder in source control and copied across when built as per the custom stuff above..
Thoughts?
I've been lazy with this of late. Umbraco is mostly frozen at 4.7 and the days of epic breaking changes are on hold until 5 comes out some time late next year. As a result I tend to stick the whole site in source control and not use the separate umbraco site pattern you mention above. This means you can branch it just like any other site if you wanted although again we've moved away from that quite a bit of late and prefer to have our sites releasable all the time rather than having several branches here and there. I'll have a parent folder with the umbraco site inside this as a child folder, then I'll add any custom C# goodies as another folder too and have a build event to copy over our DLL's to the umbraco bin folder on (successful) compile/unit test run. For ease we cheat and check in the last working version of any custom DLL's so that James (aka @welcomebrand) does not need to have visual studio running on his machine. Ideally I'd like him to pull these from our build machine once its build via a little script or something but you know what...it works for us as is so no need to worry about it yet. Simple solution is better than smartest most of the time it seems.
We all use a shared development DB and work off that. If we are installing a package then it is done as a atomic action. Meaning, clean synced up site, install package, test then commit and push. That way its all in one check in and not messing with anything else.
We have a ignore file that we use for Mercuiral/Kiln (which reminds me I really must share that) which makes what to put in source control much easier.
uSitebuilder is probably the best way to go for developers building a site and good source control, makes it next to impossible for your designers to help out though as you have to do all your doc type work via C# classes and not via the UI so its swings and round abouts. Its it is a site of any size I'd go with uSitebuilder now. Tiny sites just use the UI. We will be giving it a go on our AgenCMS site when we refactor it later in the year. Main advantage is that having commit messages for template mods is ok but there is no way to link those to DB mods that they might need to work, using uSitebuilder gives you those details. @Cultiv has had a lot of sucesse using Razor for with his setup like this too and says it works really well, no need for creating macros manually this way. That said I know @leekelleher has build a XSLT Provider which allows the same thing for XSLT macros now too. Might be worth taping him up for it.
This all works until you go live and then the lines blur quite a lot as to what you should do where, when and how. Courier 2 takes away a lot of the pain but we've not used it in anger yet mainly after talking it through with several of the build machine heavy hitters at CG11. The tool is amazing but to work well in a multi-developer environment it needs a strict workflow in place or you could really mess things up. It suffers from developers having to work on only one features/changeset at a time or you risk uploading half finished work (It works out dependancies for any file and will upload them all meaning some items could go up unfinished if you have multiple changes going on in one build). Again branching can help you here, only ever work on a feature in a branch and merge it into the main branch/trunk once ready for live. Another issues I believe exists with Courier is there is no roll back option that I know of I could be wrong there but I'm not aware of one (please feel free to correct me).
Ideally don't edit on live, content is fine but not templates, css, assets etc. once live then template updates etc. are all managed manually by source control on the servers.
Hope that helps?
Yeah loads of help, thanks.
The way we currently work in terms of making changes / adding new stuff is to create them via the Umbraco UI and then retrospectively copy them into the source controlled 'Custom' project.
What I may do is store the web root (i.e umbraco core plus any installed packages) in source control, but separate to the custom stuff.. I like the separation of custom development work (inc. css/scripts/templates) etc from the core - it's quite clean.
I'll have a play. :)
is working on a reply...