Sitecore environments

Question

Our organization's website is moving to Sitecore CMS but we are struggling with setting up the environments for Developers (4), Designers (4), QA persons (3), Authors (10-15) and Approvers (4-10) in a way where they can work independently, I know that there will be dependencies but idea is to minimize it.

Here are couple of rules:

1) Whoever is responsible for the change then they should do it everything until and unless there is any dependency.

2) If one team is working on one feature then it shouldn't stop or effect other team's work. For example, if QA is testing the feature then Derringers and Developers should continue their work on the same feature for new enhancements.

Questions related to environments:

1) Where the Designers will work? I mean where they will add their html, js and images? On which server? In Sitecore? In Source Control (TFS)?

2) How the Designers and Developers should work together? I know developers will work on their local machine's in Sitecore. And will promote their work to Integration server but How they will get the Designers stuff? Let suppose the feature has gone into production successfully now only Graphics Design changes are required, let say font styles and some images then where Designers should make these changes? On which Server? And after that how that Sitecore instance will sync with other Sitecore instances. And for design changes I do not want developers for promoting any code or file.

3) What is the safest way to sync the Sitecore environment/databases? Means whatever has been published into production website, we will need back in DEV, QA and UAT environments.

We do not want to do any manual promotion of code, html, js and image files. Is there any way to do these kind of things automatically via tool or Sitecore commands. Personally I do not like the Sitecore packages.

4) Do you know any good reference? Where I can find answers of similar questions? Any website, book, blog?

I know one document "Understanding Sitecore Deployments 6.2" but designers part and how the different environments will be synchronized are not discussed over there.

Thanks.

Quant

Answer 1

1. There’s no need for your designers to have access to Sitecore to build static markup/js/css/images but for that to be incorporated into Sitecore you will need someone to integrate it by adding sublayouts or renderings which have the markup and reference the css/js/images. If you have separated your designers and developers it is normally helpful to explain to them that you are using a asp.net web forms environment as there are special considerations to bear in mind around that (e.g. control IDs and form usage). Having them share source control with your developers is a massive advantage as it limits the amount of rework that may need to be done if both are working in tangent and making separate updates.

2. It's worth conceptualising the difference between static and dynamic content. If you need to make a "design change" which involves updating markup/css/js then you will need to push that change through your software development lifecycle in just the same way as developers do. In fact, it would be best for the developers to do that. If you need to make a change which is more "dynamic" in nature and has been developed for - e.g. updating text, links, images, even css in some cases through using Rich Text Editor fields you could of course have designers do it. They would be "editors" like anyone using a CMS. How much involvement they have in the editorial process is very much up to how far you stretch the "content based" paradigm. If you wanted, you could have all your pages just expose a rich text editor field but that would be extremely bad practice from Sitecore's perspective.

3. Check out a product called Team Development for Sitecore from Hedgehog Development.

4. There are many RSS feeds by leading sitecore developers such as John West, Alex Shyba e.t.c. There are also lots of reading lists out there.

Reportage

Answer 2

This illustration shows a way to organize your environments avoiding overlaps and blockings. Answering your questions:

1 and 2) Both Devs and Designers works at their local machines, using local Sitecore instances. They use TFS as the Source Control system so they can mutually integrate their work. Usually Designers works more in CSS, Javascrips, Images, Sublayouts (markups) and Developers at the code itself. We have a Continuous Integration server in place (Ex: TeamCity) deploying changes to 3 different environments - CI Server (for build healthcheck), QA Server (For QA) and Prod Server (for content edition and public access). When, for instance, a designer has to fix a layout issue, he will do that at his local machine, then commit changes to TFS. Next step, TeamCity will deploy changes to the CI server, if the build is Ok the QA person can trigger a build and test the fixes. If everything is working as expected, someone can trigger the build to the production server, and the fix goes live.

You have this another diagram showing details on how you can setup your Production server to separate Content Authoring and Content Delivery - Here is a search I found several blog posts on setting this up: sitecore content authoring delivery

3) You need TDS (Team Development for Sitecore) - Use this tool to serialize/deserialize items from one Sitecore instance to another. Then you can have the serialized files to TFS and share across the team and environments. The good thing is you can use TeamCity to automatically push items to CI/QA/Prod environments;

4) The main source for info on Sitecore is their SDN - You can register free (or have an extended account if you have a sitecore license)

Remission