We have 5 environments - Development, UAT, Staging, Live and DR.
Having more than 100 content editors, makes the Live Sitecore database content grow faster.
So almost every fortnight the content tree is out of sync with Development and UAT environment. When we try to develop new things, it is out dated content and sometimes new functionality breaks the live environment.
Please can anyone suggest an ideal way of keeping all the Sitecore databases in sync apart from creating packages and updating regularly so that we can follow a proper CI?
RAZL is not a solution that you should rely on for Continuous Integration, it's merely a database comparison tool.
Setting up proper CI for Sitecore is exactly what I'm doing for my current project and this is what we came up with:
TDS:
If you are willing to spend money, then take a look at TDS (Team Development for Sitecore).
It integrates with Visual Studio and provides you with tools for serialization of Sitecore items which you can then store in your source control.
A build server would then be able to pick up any changes in those serialized files and deploy them to your Test, Staging and even Production environment.
Alternative:
A free alternative to this is to use a combination of three open source modules:
Unicorn (for automatic serialization of your changes to Sitecore
items)
Courier (for package generation based on serialized items)
Sitecore Ship (for automated deployment of Sitecore packages)
I'm working with the free alternative myself at the moment and it works great.
Have you come across RAZL, it is a Sitecore Database Comparison Tool.
This is what they say about Razl:
Razl allows developers to have a complete side by side comparison between two Sitecore databases; highlighting features that are missing or not up to date. Razl allows you to find that one missing template, move it to the correct database.
It is quite incorrect to call Razl 'merely a database comparison tool' - from the first release, you could copy subtrees from one Sitecore database to another.
The initial drawback was that it could not be automated, but with Razl 3.0 (I think it started with Razl 2.4), Razl scripting was added, so you can easily automate Sitecore database syncing between environments.
To see how others use it, see Sean Holmesby's comments:
https://community.sitecore.net/developers/f/8/t/1767
and Nikola Gotsev's comments:
https://sitecorecorner.com/2014/10/27/the-amazing-world-of-razl-part-1/
It is very inexpensive, and with v3.0, it is much more powerful than the initial release, which required manual manipulation via the GUI interface.
Related
It's unclear how the repositories are connected and tied together. Each git repo has a different package of cs files, with their own unique features and design schemas. Rather than a hierarchical design structure, where in my understanding or example:
Abp-base (free git repo), would have core essentials
AbpZero-paid (membership subscription to premium git repo), would add additional features into their design that would encourage others to pay for.
AbpZeroTemplate-demo (download from website, not git), would be a sample utilizing the paid content to push and drive sales to unlock the tool to it's full potential.
I downloaded and even paid for the different tiers, but all of the contents are all over the place. When I tried to combine them so that I could take advantage of a complete product, nothing lined up properly, and I get breakage everywhere.
How am I supposed to change the crucial schema design flaws when half of the .proj links to .dll that expect the class to be structured a certain way?
Example:
User is structured: "Name", "Surname". But i want it to be "Firstname", "Lastname." Some may ask, what's the difference? Just like how "Maiden name" is different from "Last name" or "Family name." Those little nuances are'nt procedural thinking. If you went to a stranger and asked "what's your name?" and they said "Chuck Jones," you would then ask to clarify, "What's your first name?"
Each git repository is running off of a different versioning number, that doesn't match with their counterpart. AbpZero is on a stable release version 5.x, and you go to GitHub for Abp and it's saying version 3.x is stable and green. And one of them is using User<TTenant,TUser> as a class, and the other is using User<TUser>. So not only am I getting mixed signals on how they're supposed to work (because git repos point to each other, and rely on .dll for continuity) but they're also not even sharing the same coding structure.
Can anybody help me merge the old and new together, or tell me the direction on how the design is being built?
Disclaimer: I'm a contributor to ASP.NET Boilerplate
ASP.NET Core is a web framework developed by Microsoft, as you know. There are plenty different applications based on it.
ABP is an application framework on top of ASP.NET Core (and MVC 5.x but it's a different story - I skip). It tries to help real life applications on top of ASP.NET Core. It has many features like advanced authorization, background jobs, javascript proxies, DDD infrastructure and so on.. This is completely free and developed on Github: https://github.com/aspnetboilerplate/aspnetboilerplate Thousands of developers are actively using it to build their applications.
ABP framework does not provide a User Interface itself, but provides the infrastructure. So, you should create an empty ASP.NET Core application, add nuget packages, configure the framework and modules, create a UI layout and some basic pages to start your development. This is also a time consuming work. That's why we have created "STARTUP TEMPLATES". There are two startup template:
(A) A free & open source startup template can be downloaded here: https://aspnetboilerplate.com/Templates (It just gets the code from https://github.com/aspnetboilerplate/module-zero-core-template and renames solution for you). This is a simple startup template (but more powerful then ASP.NET Core's standard template when you make File > New Project).
(B) A PAID startup template, which becomes the product on https://aspnetzero.com/. This template has much much more features on top of the framework. You can see all on its web site. Since it's a paid product, the Github repository is private and only available to paid customers.
You either start with template (A) or template (B). You CAN NOT combine them. I believe it's very obvious. For instance. Microsoft provides different startup templates for ASP.NET Core: One of them is Angular, one of them is Razor Pages, one of them is empty... and so on.. So, you select one of them based on your needs.
Both of (A) and (B) templates work on the ABP framework and adds via nuget packages (it's already combined/integrated).
So, after this explanation, I believe no one would even think how to combine them.
How am i supposed to change the crucial schema design flaws when half of the .proj links to .dll that expect the class to be structured a certain way?
When you use a framework or a pre-build solution, you have significant advantages. However, there is nothing in the World that has only advantages. Every solution/framework/library will come with its own limitations, you like or not.
With that in mind.. Despite of other vendors, we provide the FULL SOURCE CODE! User class or another schema class is not inside a CLOSED/SECRET DLL. They are on nuget packages and are open source as I described before. They are framework code. If you want to change the framework code it's always possible. Just download the ABP framework on Github repository, include into your solution, remove nuget packages and add project references. Then you can freely change the User class. Source code is open & here:
https://github.com/aspnetboilerplate/aspnetboilerplate/blob/dev/src/Abp.ZeroCore/Authorization/Users/AbpUser.cs
https://github.com/aspnetboilerplate/aspnetboilerplate/blob/dev/src/Abp.Zero.Common/Authorization/Users/AbpUserBase.cs
Each git repository is running off of a different versioning number
Why we follow the same version numbers for different products those are released and developed separately? Does Microsoft have same version number for all products?
I wish i had enough money as the next guy to afford throwing around $1600 a year just to resolve issues with poorly documented code, but sadly i do not
There are thousands of customers paid it and they are happy about our product and they are renewing their licenses to be able to access to latest source code after 1 year. If anybody wants a refund, we always provide a money back without any question. Refund request ratio is smaller than 0.5% because developers love our framework and product.
My membership expired while i was resolving conflict issues with the code, and i immediately lost the ability to use git repo connected to that service
You can contact info#aspnetzero.com and request the latest version of the code (when the time your license expired). We always help to our customers about that. It would be better if you had contact with us.
I have a few (3) core projects I want to share across many solutions (12+).
So, say I have 12 websites and they use some shared back end core code (in this case I'm not talking about shared js, css or views - I'm talking about business objects, entity stuff, etc.).
I need to be able to identify which site has which version of the shared code in dev, test, prod, etc. so a developer can get the website code and get the right version of the shared code to develop or patch the website.
And then the MS build server needs to know which version of the shared code to get for the deployment.
To solve this, I'm seeing people branch that core code - which seems absurd to do 12+ times. (I do expect to branch the core code sometimes for things like hot fixes and long running projects.)
I'm also seeing people copy DLLs of the core code and check those in.
I would think I would list the dependencies for my solutions based on TFS label names somewhere so developers can easily get the apps running with the right code and given a tfs label the build server can get the code for the website and the proper version of the core code. I'm using TFS & VS 2013 at the moment too, so there's that.
So, is there a way to do this that's straightforward, supportable/scale-able and intuitive? Thanks - Peter
Labels in TFS is very limited. For example once the label created you couldn't change and update it. If one of your core projects updated, did you need to create a new label for it. If you did and use the new label for one of your solution. However you found there are some bugs in this update, you need a newer update of your core project to fix the bug. Then a newer label created, you need to manually maintain the dependencies which seems not to be an easy job.
Moreover how to list the dependencies for your solutions based on TFS label names? TFS don't have this built-in option, seems the only way is store it in a txt or someother files and check in the source control. Every time the developer open a website application need to check it first and get label from server to their workspace and work on it.
Usually the purpose of sharing code between projects is reducing maintenance. There’s two main code sharing paths: source and binary. The difference between them you could take a look at this blog: Code Sharing in Team Foundation Server
Sharing code between products is a primary cause of quality erosion and elevated bug counts. I would recommend you to build separately and sharing binary output through NuGet which use preferable.
Also take a look below similar questions:
Sharing code between solutions in TFS
TFS 2010 Branch Across Team Projects - Best Practices
We started programming in a project that uses Agile Work Item Templates. Now, there is some history of the code that we want to keep.
Also, we want to change to a customized CMMI template, so it is close to CMMI, but customized, with slightly different work items, also some new/removed ones (for testing purposes, we set it up in a different project).
How can we now merge the source (and history) from the one project with the work items from another project?
From my understanding, you could simply export/import the work item types, but then, all the reports and queries as well as the dashboard would not get updated properly as well? So all scenarios we can come up with now result in a loss of version history (simply importing the current state of the source into newly created project using CMMI and then updating the work items).
Is there a better solution?
(using TFS 2010 and VS 2010)
edit: some useful information to be found here: http://blogs.msdn.com/b/willy-peter_schaub/archive/2011/05/17/tfs-integration-tools-where-does-one-start-part-3-dust-has-settled-did-it-work.aspx - like me, you will probably especially run into trouble with the ProcessBuildTemplates
Have you considered using the TFS Integration Tools? I'm not sure about the successful migration of work items for Team Projects using different templates, but I've been able to successfully migrate code with its history between Team Projects.
In our company we are developing a normal ASP.Net application.
Now we need to transfer the application to a cloud application that will run under Windows Azure.
So we will have two version of the application
Normal installation on IIS
Runs under Windows Azure
My question is that how to manage the TFS branches. Should I create two TFS branches foreach version and do each change 2 times or is there an alternative way to handle this problem?
Thank you in advance for you help.
We did one of the project like this, where two versions of the application (regular IIS deployment and Azure) have to be maintained in parallel. Although there were substantial differences between the two versions, we used one single code base. This worked out pretty good, I think we would have more problems if we decided to go with branches.
Few hints to make it easier to use one single code base accross legacy and Azure deployments:
1: Differences in behavior in the code is easy to do with dynamic check
if (RoleEnvironment.IsAvailable)
{
// Azure specific code
}
else
{
// normal IIS code
}
Any differences in UI could be done this way by hiding/unhiding elements from the page.
2: Create separate project and solution configurations for a) IIS production deployment, b) IIS debuging, c) Azure production and d) DevFabric. Use web.config transforms to get around any differnces in web.config.
3: For debugging under DevFabric the base version (i.e. non-transformed version) of web.config is used. I found it easier to make your base web.config to be used unmodified for DevFabric environment (i.e. the transform you would create for DevFabric would be empty). This makes debugging under DevFabric easy. The side effect is that it makes it impossible to debug under Callipso. As a workaround for Callipso problem, setup normal IIS on your dev box and use WebDeploy to publish your package built using IIS debug configuration to local IIS instance.
If the differences between the branches are small, consider using conditional compilation to switch between different platforms - this eliminates the need to branch and makes it easy to see when you're working on parts of the code that are branched. Similarly you can use abstract classes with a concrete implementation for each platform, which is a much cleaner approach than using #if on lots of small chunks of code.
If branching, then I'd use one of two approaches: if the differences are isolated, possibly consider refactoring the code to collect the differences into a small area of the codebase, and just branch that bit. Or insert a root level folder and branch there so that absolutely everything is branched.
When you make changes in one branch you will have to merge those changes across to the other branch, which is why I'd try to minimise the scope of the branches, to minimise the need to merge.
We're starting new web site development with Umbraco, and having some difficulties with optimal setup for multiple developers.
Right now we have a complete umbraco install in a code directory, with IIS pointing to it as well, and a local DB for each developer. We're planning to use Courier package to push/pull content changes, and Git for source code.
This setup allows to debug from Visual Studio (using F5), instead of attaching to a w3p, which is annoying. Separate db is a part I don't really like, I'd prefer a shared one, but with Umbraco's caching model (in xml file) this isn't optimal either - changes to data types etc are not reflected in other developer's environments. This does mean, however, that sharing changes among developers is a 2-stage process - Git + Courier.
I'd guess people have already came up with some best practices on umbraco setup for team development - would be nice to hear about them.
Thanks !
We use a central source control system for the code and share one database with all developers. This works quite good, but after a change or update of the source control repository, the only thing to keep in mind is that you need to update the cache (right click the root content-node in Umbraco and "republish entire website").
With this setup we all share the code and database in the development stage. Courier can then be used to transfer umbraco content back and forward to the test and production environment.