Sitecore environments - sitecore

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.

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.
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.
Check out a product called Team Development for Sitecore from Hedgehog Development.
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.

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)

Related

Django project-apps: What's your approach about implementing a real database scheme?

I've read articles and posts about what a project and an app is for Django, and basically end up using the typical example of Pool and Users, however a real program generally use a complex relational database, therefore its design gravitates around this RDB; and the eternal conflict raises once again about: which ones to consider an application and which one to consider components of that application?
Let's take as an example this RDB (courtesy of Visual Paradigm):
I could consider the whole set as an application or to consider every entity as an application, the outlook looks gray. The only thing I'm sure is about this:
$ django-admin startproject movie_rental
So I wish to learn from the expertise of all of you: What approach (not necessarily those mentioned before) would you use to create applications based on this RDB for a Django project?
Thanks in advance.
PS1: MORE DETAILS RELATED ABOUT MY REQUEST
When programming something I follow this steps:
Understand the context what you are going to program about,
Identify the main actors and objects in this context,
If needed, make an UML diagram,
Design a solid-relational-database diagram, (solid=constraints, triggers, procedures, etc.)
Create the relational database,
Start coding... suffer and enjoy
When I learn something new I hope they follow these same steps to understand where they want to go with their actions.
When reading articles and posts (and viewing videos), almost all of them omit the steps 1 to 5 (because they choose simple demo apps), and when programming they take the easy route, and don't show other situations or the many supposed features that Django offers (reusability, pluggability, etc).
When doing this request, I wish to know what criteria is used for experienced programmers in Django to determine what applications to create based on this sample RDB diagram.
With the (2) answers obtained so far, "application" for...
brandonris1 is about features/services
Jeff Hui is about implementing entities of a DB
James Bennett is about every action on a object, he likes doing a lot of apps
Conclusion so far: Django application is a personal creed.
My initial request was about creating applications, but as models are mentioned, I have this another question: is with a legacy relational database (as showed in the picture) possible to create a Django project with multiple apps? this is because in every Django demo project showed, every app created has a model with their own tables, giving the impression that tables do not interact with those of other applications.
I hope my request is more clear. Thanks again for your help.
It seems you are trying to decide between building a single monolithic application vs microservices. Both approaches have their pros and cons.
For example, a single monolithic application is a good solution if you have a small amount of support resources and do not need to be able to develop new features in fast sprints across the different areas of the application (i.e. Film Management Features vs Staff Management Features)
One major downside to large monolithic applications is that eventually their feature sets grow too large and with each new feature, you have a significant amount of regression testing which will need to be done to ensure there aren't any negative repercussions in other areas of the application.
Your other option is to go with a microservice strategy. In this case, you would divide these entities amongst a series of smaller services and provide them each methods to integrate/communicate with each other (APIs).
Example:
- Film Service
- Customer Service
- Staff Service
The benefits of this approach is it allows you to separate capabilities and features by specific service areas thus reducing risk and regression testing across the application when new features are deployed or there is a catastrophic issue (i.e. DB goes down).
The downside to this approach is that under true microservice architecture, all resources are separated therefore you need to have unique resources (ie Databases, servers) for each service thus increasing your operating cost.
Either of these options is a good option but is totally dependent on your support model and expected volumes. Hope this helps.
ADDITIONAL DETAIL:
After reading through your additional details, since this DB already exists and my assumption is that you cannot migrate it, you still have the same choice as to whether or not you follow a monolithic application or a microservices architecture.
For both approaches, you would need to connect your django webapp the the specific DB you are already using. I can't speak for every connector out there but I know that the MySQL connector allows django to read from the pre-existing db to systematically generate the models.py file for the application. As a part of that connector, there is a model variable which allows you to define whether or not Django is responsible for actually managing the DB tables themselves.
The only thing this changes from an architecture perspective is how many times do you want to code this connection?
If you only want to do it once and completely comply with the DRY method, you can build a monolithic application knowing that as new features become required, application wide regression testing will be an absolute requirement.
If you want ultimate flexibility for future changes with this collection of features and don't mind recoding the migration across multiple apps while reducing the need for application wide regression testing as new features become required, a microservice architecture strategy is more appropriate.

What is the difference between 'SAS' and 'Salesforce'

I would be starting ft in one company, where i was been told that the application is developed using 'Sas' and 'salesforce'. What is the difference between two?
And which are recommended online resource which I can use to learn more about it.
SAS is software for statistical analysis. If your company/job description doesn't look like working with large sets of data & complex reporting that's probably not it.
They probably mean SaaS (Software as a Service) model, also known as "the cloud", cloud computing etc. You write the program (or use / modify existing one) but you don't buy servers, worry about network connection, electricity costs, load balancing (spikes in traffic will not cause your website to go down). Many apps operate in this model. Microsoft's Azure cloud (or even online wersions of MS Office). There's Siebel Oracle on Demand CRM, Microsoft Dynamics, SAP I think also has SaaS offering...
It's a big topic, I'm simplifying a lot here. And then there are Platform as a Service things too (PaaS) where they give you "just" the hosting etc but no base application to build on top of. You write everything you need from scratch and upload it. Think Heroku or Amazon Web Services (AWS).
Salesforce is "just" one more SaaS application. You start with base application & database, similar to all other clients in the world. You can install plugins to it (some free, some paid), configure it yourself, write custom code if your functionality is too complex... You can do a lot with just clicks & drag & drop but if you need to code stuff then JavaScript (for client-side) and Apex (for server-side) will be your friend. Apex is bit similar to Java.
Where to start... Trailhead is good source of self-paced trainings. You can sign up for a free Salesforce Developer Edition (has almost all features as the paid one but limited storage space), try to pass some courses... Or in SF help&training there should be tons of videos (actually in that link whole left menu "getting started with salesforce" might be good).

How to migrate a web application to another technology in a seamless, incremental way

I have a Coldfusion application, developed without any framework and almost no architecture.
I'd like slowly migrate some part of the application to some kind of java based web application framework.
The original application must still be the main application all the way until the end of the migration.
The application has user and sessions and a lot of functionalities, not easy to decouple.
I'm looking for different ideas.
For example I could try to develop a REST API backe nd and start to use it from the ColdFusion application until I'll have Coldfusion only as front end. This process must go hand by hand with database refactoring and migrations, ie. new API must use its own database, so I guess that decoupling of database will be necessary (and probably database synchronization issues will arise)
But I would like to switch also to a different front end technology.
The situation would be like: Users login in coldfusion, enter main dashboard in Coldfusion and next "some" functionalities will be handled by another framework. That means a template engine is able to understand the user, his roles, his permissions, reproduce the same graphical layout, but it should serve the content with another technology.
Final result must be that all functionalities are migrated to the new technology.
I mention Java as it is in some way related to ColdFusion, but any web application framework could be used in principle.
I also think that Coldfusion is used in the original application is not relevant. The fact that no framework is used, probably gives me more flexibility.
Any architectural suggestion is welcome.
I recently did this very thing. A spaghetti code app developed by a graphic designer with a CFML book, a MSSQL database so denormalized not even Bizarro could have wrestled it and won.
What we did was we left the old app in place, built a new one and tested it extensively, perfected it, made sure it was capable of evolving (and it has). Then we flipped a DNS switch and sent out an announcement that the new system is the only option going forward.
I then built an archive feature that provided read-only access to the mess that we left behind. Some day, if the app owners want to migrate that data, we can try that (it won't go well), but generally the vast improvements have convinced everyone that the old stuff is only needed in that read-only mode.
Obviously that means reporting only goes back to the first day of the new tool, but it was either that (with a 4 week dev time) or they get it all and it takes 8 months doing what you described.
It's worked very well for us, and it's probably been the best-received work I've done here.

Recipes and Design Patterns for Web App Components

I'm currently working with a team of developers on a company project to create a centralized repository of product and pricing information. This will be built for both internal company use and external client use. On top of the basic features of storing product and pricing information we also need to build up an infrastructure to accommodate:
REST API endpoints
Dev/Staging/Deployment workflows (particularly for performing updates on records in a live environment)
Logging
Analytics
Reporting
Security (authentication and authorization).
Going over the list, it reads like a very common set of requirements for a web application and I doubt my company is breaking any sort of new ground. SO, is there any particular resources (frameworks, technology stacks, articles, books) that can help me understand how other web applications are tackling these problems?
A bit of background on the team. The team has worked on a handful of small-to-medium sized web applications using PHP, Mongo and MySQL for the backend, and basic HTML, CSS, JQuery on the frontend. The team is familiar with design patterns (i.e.Gang of Four) but to date have not worked on anything requiring all of the elements listed above
It's probably worth playing around with a solid Web development framework like Zend, Yii or even Ruby on Rails or Django, which are not PHP frameworks, but are fairly mature and well structured. Even if you do not plan to use that framework for development you'll get some great ideas for how to structure your web applications, how to implement logging and common web security features.
As far as deployment and workflows go, you may want to give Extreme Programming a read if you haven't already. It describes what many developers today considered to be a fairly classic agile project management methodology, but it also gets into important practices such as testing and continuous integration, which in my opinion are incredibly important components of the development workflow. If you're starting from scratch as a team you'll benefit enormously from implementing a solid agile methodology -- or at the very least from a solid foundation in testing and continuous integration.
For examples of REST style applications you may want to see how popular open source implementations work. Some of these frameworks will have a REST structure built in, but there are many open source options, some of which are discussed here.
For analytics, Google has quite a bit of documentation here.
As far as reporting goes, I'm not clear on what you need, but if you're talking about log parsers and bug or downtime reporters there are some excellent tools out there, including continuous integration automation tools such as Atlassian's Bamboo that will provide some reporting assistance. These can help you with part of the reporting process, but from my experience a large, complex web application can benefit from custom reporting elements, considered as part of the development process from the beginning. It's not that difficult to parse logs programmatically, I don't think there's a one size fits all implementation.
As a side note, Atlassian has some excellent development tools if you're willing to pay for them, but open source alternatives shouldn't be difficult to find, such as the ubiquitous Trac for ticket tracking, and basic project management with an integrated wiki.
I can't say I know of a single, comprehensive location that provides you all the information you need (at least not yet!), but hopefully you'll glean something interesting from this answer. Starting on some serious web development projects with a fresh team (if I interpreted your situation correctly) can be a really enjoyable challenge. Good luck!

Has anyone built web-apps that can run totally off-line? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I'm building an app that authors would (hopefully) use to help them, uh.. author things.
Think of it like a wiki but just for one person, but cooler. I wish to make it as accessible as possible to my (potential) adoring masses, and so I'm thinking about making it a web-app.
It certainly doesn't have to be, there is no integration with other sites, no social features. It involve typing information into forms however, so for rapid construction the web would probably be the best.
However, I don't really want to host it myself. I couldn't afford it for one, but it's mostly that people who use this may not want their data stored elsewhere. This is private information about what they are writing and I wouldn't expect them to trust me with it, and so I'm thinking about making it a thick-client app.
And therein lies the problem, how to make a application that focuses mainly on form data entry available easily to potential users (yay web apps) but also offline so they know they are in full control of their data (yay thick-client apps).
I see the following solutions:
Build it as a thick-client Java app and run a cutdown version on the net as an applet that people can play with before downloading the full thing.
Build it as a Flex app for online and an Air app for offline (same source different build scripts basically).
Build it as a standard web-app (HTML, JS etc) but have a downloadable version that somehow runs the site totally on their computer. It wouldn't touch the net at all.
Ignoring 1 and 2 (I'm looking into them separately), I think 3 would involve:
Packaging up an install that contains a tiny webserver that has my code on it, ready to run.
Remapping the DB from something like mySQL to something like SQLite.
Creating some kind of convience app that ran the server and opened your browser to the right location, possibly using something like Prism to hide the whole broswer thing.
So, have you ever done something like this before?
If so, what problems did you encounter?
Finally, is there another solution I haven't thought of?'
(also, Joyent Slingshot was a suggestion on another question, but it's RoR (which I have no experience in) and I'm 99% sure it doesn't run under linux, so It's not right for me.)
I think you should look at tiddlywiki for inspiration.
It's a wiki written in JavaScript entirely self-contained in a single html file. You load it into your browser as a file:/// URL, so there is no need for a server.
I use it as a personal wiki to keep notes on various subjects.
Google Gears is used to offer a few of the google apps offline (Google Reader, Gmail, Docs and more).
What is Google Gears?
Gears is an open source browser extension that lets developers create
web applications that can run offline.
Gears provides three key features:
A local server, to cache and serve application resources (HTML,
JavaScript, images, etc.) without
needing to contact a server
A database, to store and access data from within the browser
A worker thread pool, to make web applications more
responsive
by performing expensive operations in
the background
Gears is currently an early-access developers' release. It is not yet intended for use by real users in production applications at this time.
If you're a developer interested in using Gears with your application, visit the Gears Developer Page.
If you wish to install Gears on your computer, visit the Gears Home Page. Please note, however, that Gears is not yet intended for general use.
But as you read it's still in early stages.
There is an additional option, and that is to use the new HTML5 offline application features, namely the Application Cache, Client-Side Databases, and Local Storage APIs.
Currently I believe that Safari is the only shipping browser to support any of these, and i believe it only supports the client side databases and local storage parts. The webkit nightlies support all of these features, the firefox nightlies support many of them (maybe all now?)
[Edit (olliej): Correction, Firefox 3 supports the Application cache, but alas not the client side DB]
We are using something similar to your third option to test our websites locally. Works just fine.
Our packaged webserver is not small enough to accomplish what you need, but then again we've not been trying to keep it small either. If you can package your webserver code into a small enough package I don't see why this approach would'nt work.
I think AIR is the way to go..
Have you checked into google gears?
Some pointers for solution 3:
for the GUI part, ExtJS seems really nice.
for the storage part, there is a nice javascript library that abstracts different storage backends: PersistJS.
Supported backends for PersistJS:
flash: Flash 8 persistent storage.
gears: Google Gears-based persistent storage.
localstorage: HTML5 draft storage.
whatwg_db: HTML5 draft database storage.
globalstorage: HTML5 draft storage (old spec).
ie: Internet Explorer userdata behaviors.
cookie: Cookie-based persistent storage.
Also, I think the moin moin wiki software has a desktop version that includes its own webserver. This stuff is easy in python, since batteries are included.
You might want to check out how they do it?
You could make a dedicated client using Webkit or Firefox's backbone. Some games use that solution for UI for example.
Or you could make a little webserver (I have a little webserver in Lua that I use for similar purposes, just a few megas with libaries and all). However if you take this route the biggest issue to consider is you don't want your webserver to depend on environmental variables, you want it to be totally autonomous. You should try to isolate all variables t o a config file and be done with it (bundle style)
Or you could use a Java client application to display the webpage
Or GoogleGears, but that's the same (almost) as Flex+Air. so choose Flex+Air if that's what you are familiar with
You didn't specify a language but I looked at Karigell a few years ago. It's Python web framework, similar to Django or TurboGears, but it doesn't have the overhead of those frameworks.
From my messing around with it, it seems like it would work for your purposes. It has a built-in web server (though you can use pretty much any server you want) and you can use any database that Python supports.
Plus, Python works well with Linux. :)
If you made the app a regular web app heavily reliant on client-side technologies (using DHTML and the likes of Google Gears to store data offline as already suggested) so once opened, there wasn't much interaction with the server, you could probably host the thing on a basic shared hosting account which wouldn't cost that much. That might be your easiest starting point as you wouldn't have to worry about all the issues with desktop apps such as compatibility with different operating systems, packaging up an install etc, yet you wouldn't need massive server resources behind it either.
You can use HTML, JS and whatever else in Adobe AIR and you'll have plenty of options of saving data locally, too.
in java world you could use jetty for a server, implement web app using your favorite framework and use hsqldb as a database - it lives entirely in your container (jetty). you can deploy preview app on the web and package downloadable offline version.
There's a portable distribution of Apache/MySQL/PHP (to place on USB keys):
http://portableapps.com/apps/development/xampp
This should be easily adapted to your needs.
You could also consider using XULRunner or Prism
They're the opensource technology that FireFox, Thunderbird and Joost are built on, and allows you to develop apps in XML and javascript essentially against the same rich api that FireFox itself has. And of course this is cross platform too, so it'd work on Mac/Linux/Windows...
Check here for more info:
https://developer.mozilla.org/en/XULRunner
I was thinking of doing something like this myself. My plan was to write app using django and write script that starts django's testing server and opens default browser on specified port. My plan was to use SQLite...
Also, it would be nice to pack it into one package, so users without django installed can run app without any dependecies...
My suggestion, as you pointed above, is to use a Wiki system to solve your problem. Now the question could be: Wich one?
You can use Trac, it is very simple and you can customize its GUI. But, if you prefer something more advanced please use MoinMoin. I used it for years, and IMO it is a very good and strong wiki system.
Depiste wich wiki you will choose, forget to write your web-app from scratch. According to yor question the best approach is to pick something that works and customize/modify it to fit your needs.