The domain.xml file is huge, with large <profile> sections. Each <profile> section has a lot in common.
Is it possible to split it something more modular ? My guess is no because the server has to rewrite the whole domain.xml file at any change, and because I've never read anything about it.
But, I'm still asking the question as it hurts my DRY developer eyes. (Don't Repeat Yourself)
The real answer is you shouldn't edit the raw XML :) The short answer though is no.
It's best to either use the web console or use CLI to manage the profiles. You can use CLI script files as well.
Related
I am planning an enterprise deployment of SiteCore...
Users can edit the content only on the backend servers.... and I was planning to DEPLOY in production only the required files & configuration required to run my site properly... (the Vanilla SiteCore site stripped out of the SiteCore folders...)
so I guess that I need 100% SiteCoreAssemblies and Config... more specifically I was wondering how to remove from the config all the unused stuffs required for the web edit and content approval roles....
let me know if there is any guidance / best practice... or any advise to improve the security and deploy the minimum configuration to run, would be appreciated...
Thanks Stelio
The only reason I'm digging this up is because I'm doing this in the near future:
Take a look that the "Configuring Production Environments" document that #Christian Hagelid pointed out.
More specifically: 1.2.2 Step 2. Clean the solution (optional)
Remove unnecessary files Delete the following files:
/Indexes folder - If you are not using indexes in your implementation.
Everything from the /sitecore folder except: -/service -shell/sitecore.version.xml -/login/default.css -/images
/App_Config/Commands.config
/App_Config/ConnectionStringsSQLite.config
/App_Config/Prefetch/Core.config
/App_Config/Prefetch/Master.config
/App_Config/Icons.config
/App_Config/LanguageDefinitions.config
/App_Config/Portraits.config
/WebSite/web.config.sqlite *
/WebSite/webedit.css
Remove or comment the following sections from the web.config file:
events
workflowHistoryStores
processors
dataviews
pageextenders
controlSources
replacers
fastCache for "shell" site.
watcher
commands
languageDefinitions
icons
portraits
publishing
watchers-media and watchers-config
ConfigWatcher from httpModules and system.webServer/modules
Filesystem database definition from databases
Remove or comment the following scheduled agents in the Web.config:
CleanupPublishQueue
CleanupAgent’s timing intervals should be adjusted if necessary
HtmlCacheClearAgent if not used
I challenge you to be brave and experiment with settings. Go through the web.config file line by line and make sure you understand them. I do this periodically to remind myself of features Sitecore has that I'm not taking advantage of. Try to remove some settings that you don't think you need and when they work and you're happy with them, share your findings.
Take FULL advantage of caching - Sitecore has wonderful options for caching and if properly configured your site will be fast, on the other hand if you don't properly configure caching your site could be really slow and or have weird issues with dynamic content being cached incorrectly.
Good luck!
There's a document called "Configuring Production Environments" which covers this. It's a little old but could be a good starting point at least.
Other documentation that might help:
Chapter 4.6 (How to: remove References to the Master Database) of the Scaling Guide
Chapter 7 (Content Delivery Server Optimizations) of the CMS Performance Tuning Guide
You should probably take a look at the Sitecore Security Hardening Guide to start with. It should provide you with a great start on best practices for setting up a secure production content delivery system.
As I recall, the easiest way to do this is actually through the license file. Sitecore should be able to provide a "webfarm" license that disables all editing functionality. There's no guide I know of as to folders you can delete, or sections from the web.config, and doing so will likely have undesirable side-effects.
I'm currently working on a project that's been going on for several years straight. The development-team is small (less than 5 programmers), and source-control is virtually non-existent, and the deployment-process as is is just based on manually moving files from one server to another. The project is in classic ASP, so building isn't an issue, as both deployment and testing is just about getting the files to where they need to be and directing the browser at the correct location. Currently all development is done on a network-drive which is also the test-server. The test-server is only available when inside the the local network (can be accessed trough vpn), and is available on the address 'site.test' in the browser (requires editing to the hosts-file on all the clients, but since there are so few of us that hasn't proven to be any problem at all). All development is done in visual studio. Whenever a file is change the developer that changed the file is required to write the file he changed into a word-document and include a small description as of what was changed and why. Then, whenever there's supposed to be a version-bump (deployment), our lead-developer goes trough the word-document and copies every file (file by file) that has changed over to the production-server. Now, I don't think I need to tell you that this method is very error prone (a developer might for instance forget to add that he changed some dependency, and that might cause problems when deployed), and there's a lot of work involved with deploying.
And here comes the main question. I've been asked by the lead developer to use some time and see if I can come up with a simple solution that can simplify and automate the "version-control" and the deployment. Now, the important thing is that it's as easy as posible to use for the developers. Two of the existing developers have worked with computers for a long time, and are pretty stuck up in their routines, so for instance changing it into something like git bash wouldn't work at all. Don't get me wrong, I love git, but the first time one of them got a merge-conflict they wouldn't know what to do at all. Also, it would be ideal to change to a more distributed development-process where the developers wouldn't need to be logged into vpn (or need internet at all) to develop, and the changes they made offline could be synced up when they were done with them. Now, I've looked at Teem Development Server from Microsoft because of it's strong integration with Visual Studio. As far as I've tested it seems possible to make Visual Studio prompt the user if they want to check in changes whenever the user closes Visual Studio. Now, using TFS for source-control would probably eliminate most of the problems with the development, but how about deployment? Not to mention versioning? As far as I've understood (I've only looked briefly at TFS), TFS has a running number for every check-in, but is it possible to tell TFS that this check-in should be version 2.0.1 of the system (for example), and then have it deploy it to the web-server? And another problem, the whole solution consists of about 10 directories with hundreds of files in, though the system itself (without images and such) is only 5 directories, and only these 5 should be deployed to the server, is this possible to automate?
I know there's a lot of questions here, but what is most important is that I want to automate the development process (not the coding, but the managing of the code), and the deployment process, and I want to make it as simple as possible to use. I don't care if the setup is a bit of work, cause I got enough time at hand to setup whatever system that fits our needs, but the other devs should not have to do a lot of setup. If all of the machines that should use the system needs to be setup once, that's no problem at all, cause I can do that, but there shouldn't bee any need to do config and setups as we go.
Now, do any of you have any suggestions to what systems to use/how to use them, in order to simplify the described processes above? I've worked with several types of scm-systems before (GIT, HG and SubVersion), but I don't have any experience with build-systems at all (if that is needed). Articles, and discussion on how to efficiently setup systems like this would be greatly appreciated. In advance, thanks.
This is pretty subjective territory, but I think you need to get some easy wins first. The developers who are "stuck up in there ways" are the main roadblock here. They are going to see change as disruptive and not worth it. You need to slowly and carefully go for the easy wins.
First, TFS is probably not going to be a good choice. It's expensive, heavy, and the source control in TFS is pretty lousy. Go for Subversion: it's easy to setup and easy to use, and it's free. Get that in place first, and get the devs using it. Much easier said than done.
Later (possibly much later), once the devs are using it and couldn't imagine life without a VCS, then you could switch to Hg or Git if you need first class branching and all those other nice features.
Once you have Subversion in place, you can use something like JetBrains TeamCity or Jenkins, both of which are free and easy to use. However, I'm just assuming you don't have a lot of tests and build scripts that the CI server is really going to be running, so it's far more important that you get VCS first. In all things: keep it as simple as possible. Baby steps. Get some wins, build trust, repeat.
I can't even begin to think where to begin with this! Intending no offense directed at you, apart from the mention of git and HG, this post could have been written 10 years ago.
1) Source control - How can a team of developers possibly work effectively without some form of source control? Hell, even if it's Visual Source Safe (* shudder *) at least it would be something. You have to insist that the team implement source control. You know what's available so I won't get into preaching about that. (However, Subversion with TortoiseSVN has worked quite well for me.)
2)
"write the file he changed into a
word-document and include a small
description as of what was changed and
why"
You have got to be kidding... What happens if two developers change the same file? Does the lead then have to manually merge two changes that s/he extracts from the word doc? Please see #1 and explain to them how commit comments work.
Since your don't really need to "build" (i.e. compiled, etc.) anything, you should be able to solve most of your problems with some simple tools. First and foremost you need to use a source control solution. Yes, the developers would have to learn how to use another tool (EEEK!). You could do the initial leg work of getting the code into the repository. If you have file access to the other developers machines, you could even copy a checked-out working copy to their machines so they wouldn't have to do the checkout themselves (not really that hard). You could then use all the creamy goodness of version control to create version branches when each deployment needs to be done. You could write simple scripts using the command line SVN tools to check out said branches and automatically copy the files to the target server(s). Using a tool like BeyondCompare, the copy process could be restricted to only the files that are different (plus BC can handle an FTP target if that is an issue). By enforcing commit comments on the SVN repo, you'll guarantee that the developers provide comments, and for each set of changes between releases you could very easily generate a list of all those comments using the CSM log retrieval features.
I'm developing a web app.
If I include a jQuery plugin (or the jQuery file itself), this has to be put under my static directory, which is under SCM, to be served correctly.
Should I gitignore it, or add it, even if I don't plan on modifying anything from it?
And what about binary files (graphic resources) that might come with it?
Thanks in advance for any advice!
My view is that everything you need for your application to run correctly needs to be managed. This includes third-party code.
If you don't put it under SCM, how is it going to get deployed correctly on your production systems? If you have other ways of ensuring that, that's fine, but otherwise you run the risk that successful deployment is a matter of people remembering to do all the right things, rather than some automated low-risk "push the button" procedure.
If you don't manage it under SCM or something similar, how do you ensure that the versions you develop against and test against are the same? And that they're the same as production? Debugging an issue caused by a version difference you don't notice can be horrible.
I generally add external resources to my project directly. Doing so facilitates deployment and ensures that if someone changes the version of this file in your project, you have a clear audit history of what happened in case it causes issues in the code that you've written. Developers should know not to modify these external resources.
You could use something like git submodules, I suppose, but I haven't felt that this is worth the hassle in the past.
Binary files from external sources can be checked in to the project as well, although if they're extremely large you may want to consider a different approach.
There aren't a lot of reasons not to put external resources like jQuery into your repo:
If you pull it down from jQuery every time you check out or deploy, you have less control over which version you're using. This holds true for most third-party libraries; you probably don't want to upgrade your libraries without testing with your code to see if it breaks something.
You'll always have a complete copy of your site when you check out your repository and you won't need to go seeking resources that may have become unavailable.
For small (in terms of filesize) things like jQuery and images, I'd just add them unless you're really, really concerned about space.
It depends.
These arguments relate to having a copy of the library on your system and not pulling it from it's original location.
Arguments in favour:
It will ensure that everything needed for your project can be found in one place when someone else joins your development team. I've lost count of the number of times I've had to scramble around looking for the right versions of libraries in order to be able to get something working.
If you make any modifications to the library you can make these changes to the source controlled version so when a new version comes out you use the source control's merging tools to ensure your edits don't go missing.
Arguments against:
It could mean everyone has a copy of the library locally - unless you map the 3rd party tools to a central server.
Deploying could be problematical - again unless you map the 3rd party tools to a central server and don't include them in the deploy script.
I have a scenario where I am asking consultants to deploy 2 applications. A console application and an IIS web service application. Both apps form part of the solution.
I haven't created an easy to use installer, but was wondering if there is an open source config editor that I can ship with my app that can read in "only certain" values and allow the consultant to change these values.
This would be much less hassle than asking the consultant to open up web.config or app.config - because the configuration is pretty complex for a non technical person, and they're overwhelmed by all the XML.
I guess as a programming question, this would be a question relating to deployment.
What exactly are the sections which you want the developers to read ? I would refer you to this question Can a web.config read from an external xml file?. You can keep part of your web/app.configs externally and read from them.
more reference:http://blog.andreloker.de/post/2008/06/Keep-your-config-clean-with-external-config-files.aspx
Simple usecase: assemble an Eclipse product using simple scripts, just dumping bundles into the plugins dir.
This used to work with 3.3 - with 3.5 it's broken: my application doesn't start as the app plugin is not found.
Question: what's the easiest way to fix that? This seems to be the only pain in the whole upgrade process for me.
Attempts:
I guess this is a no-no for P2: it maintains the bundles.info file instead, which is probably very smart.. a bit too smart for me.
Some ideas I had:
can I just skip P2 altogether and get back to plain old, simple -dirty- discovery mechanism?
can I set up plugins dir as a 'watched directory'
looks like I need to use the p2.reconciler for that.. oh wait, it's deprecated already :-( bug 251561.. (thanks VonC for the pointer)
can this old setting in the config.ini still work? (which is now replaced with the 'simpleconfigurator') osgi.bundles=org.eclipse.equinox.common#2:start, org.eclipse.update.configurator#3:start, org.eclipse.core.runtime#start
should I call the (p2) director?
"please pick my plugins up" :)
I'd avoid the dropin folder for this - that's more for the
end-users.
I'd avoid messing with the bundles.info if possible.
I don't care about all those smart features in my product yet- actually the users don't use the built-in update mechanism at all.
So I'd like to KISS (ie: just to start up), and add more advanced support when needed.
I've asked this on Eclipse forums, but no answer yet, so would really be grateful for some enlightenment.
Also, feel free to correct me on the assumptions - I've just read the P2 docs, which seem confusing at times.
Thanks!
Answer: actually option 3 above seems to work after all - thanks Francis for confirming this! (it didn't work originally, but that was probably caused by some missing deps).
My only issue with that now is, some Eclipse bundles actually require simpleconfigurator. So I wonder if swapping it out will cause problems down the line.
You can alter your configuration/config.ini file to not use the org.eclipse.equinox.simpleconfigurator (which does the p2-based configuration) and instead use the org.eclipse.update.configurator which is the old-school way of just configuring whatever is in the plugins directory. This should give you what you want.
Even if it does not fully answer what you are after, you can specify in an eclipse.ini (like the one I describe here):
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:/jv/eclipse/mydropins
That does specify to p2 to monitor any directory of your choosing to detect plugins in it.
Another source of idea could be this article: Composing and updating custom Eclipse distros
It's not hard to create a feature based product that includes these things, and do a product build to end up with something like this:
Note: the concept of reconciliation is detailed in the eclipse Wiki.
For certain installations of Eclipse, there will exist the notion of a shared installation -- this may be in the case of a Linux system where a base set of software is installed via packages (perhaps RPMs), or may be in a Maya deployment where shared profiles are defined in a central server.
In both cases, it is necessary to perform reconciliation between the shared profile and the user's current instantiation of the profile including any modifications they may have made.
Part of this mechanism is the Dropins Reconciler setting. Although, as bug 251561 illustrates, it is not advised to put too many plugins in there.
Maybe this will help you (shot in the dark)? I found this when upgrading my Eclipse installation to Galileo and trying to keep my Flex Plugin install.