We have replicated our base Ektron site over 100 times (different clients) and between copies on the web servers and putting sites in SVN, I have decided to pull out the scalpel and slim down the workarea.
Folders that I find take up the most space:
\Help
\Documentation
\eWebEditPRo
\eWebDiff
\Foundation\RadControls\Spell\TDF (lots of unneeded language files)
Has anyone done this and what have you cut?
You might want to look at the GeoIP files in App_Data, especially if you're not using any geolocation.
(GeoIPOrg.dat ~140MB, GeoLitCity.dat ~30MB, GeoIPDomain.dat ~5MB)
The current version of ektron (v8.5) supports a true 3-tier architecture. This is relevant to your situation because it would allow you to have a single full Ektron installation on the middle-tier (application server), and have a very minimal configuration on the front-end (presentation server). The minimal configuration on the presentation server would not require you to have any workarea folder, nor would it require all of the DLLs in the bin folder. Ultimately it gives you great control over what you place on your front-end presentation server.
I have a webinar on this exact configuration coming out on 9/15/2011. It will cover installation, configuration, the developer experience, best practices, etc. If you're interested, keep an eye on this page http://www.ektron.com/Resources/Webinars/. If you visit this link after 9/15/2011, the webinar should be recorded, archived, and available on that page.
Related
In our small office we're setting up mercurial - our first time using a "real" version control system. We've got three servers - a live server, a staging server and a development server.
We've also got three relatively large web sites - one for visitors, one for users and an intranet site, for the office staff.
The three web sites share some code. (for instance - a php class library, some commonly used code snippets, etc.)
Before version control, we just used symbolic links to link to the shared libraries. For example: each site had a symbolic link to an "ObjectClasses" directory - any changes made to a file in ObjectClasses would be instantly available to all the sites. You'd just upload the changed file to staging and to live, and you were done.
But... Mercurial doesn't follow symbolic links. So I've set up a subrepository for the shared libraries in the three sites on the three servers (actually 'four' servers if you count the fact that there are two programmers with two separate clones of the repository on the development server).
So there are 12 working copies of the shared object library.
So here's the question:
Is there any way to simplify the above set up?
Here's an example of what our workflow will be and it seems too complicated - but maybe this is what it's like using version control and we just need to get used to it:
Programmer A makes a change to Object Foo in the subrepo in Site 1. He wants to make this available everywhere, so he commits it, then pushes it to the staging server. I set up hooks on the staging server to automatically propogate the changes to the three sites, on the staging server, and again to the three sites on the live server. That takes care of the 6 working copies on the staging and live servers. So far, so good.
but what about the development server, where there may be work-in-progress on these files?
Programmer A now needs to manually pull the shared subrepo to Sites 2 and 3 on the development server. He also needs to tell Programmer B to manually pull the shared subrepo on Sites 1, 2 and 3 on his copy of the site on the development server. What if he's editing Object Foo on Site 1 and making different edits to Object Foo on Site 2. He's going to have to resolve two separate conflicts.
We make changes to the objects relatively frequently. This is going to drive us nuts. I really love the idea of version control - but after two weeks of wrestling with trying to find the best setup, the old sloppy way of having one copy of the shared files and calling out "hey - ya working on that file, I wanna make a change" is looking pretty good right now.
Is there really no simpler way to set this up?
Without more information about the specific web platform and technologies you're using (e.g., .NET, LAMP, ColdFusion, etc.), this answer may be inadequate, but let me take a stab nevertheless. First, if I understand you correctly, it's your working paradigm that's the problem. You're having developers make changes to files and then push them to three different sites. I suggest separating the development concerns altogether from the build/deploy concerns.
It sounds like you're using subrepositories in Mercurial to handle shared code--which is smart, by the way--so that's good. That takes care of sharing code across multiple projects. But rather than have each programmer pushing stuff to a given server after he updates it, have the programmers instead be pushing to some other "staging" repository. You could have one for each of your servers if you wish, though I think it probably makes more sense to keep all development in a single staging or "master" repository which is then used to build/deploy to your staging and/or live server.
If you wish to automate this process, there are a number of tools that can do this. I usually prefer NAnt with CruiseControl for build integration, but then my work is mostly .NET which makes it a great fit. If you can provide more specifics I can provide more details if you like, but I think the main problem for you to overcome is the way you're handling the workflow. Use Mercurial to keep multiple developers happy pulling/pushing from a single repository and then worry about deploying to your servers for testing as a separate step.
Our repositories are getting huge because there's tons of media we have ( hundreds of 1 MB jpegs, hundreds of PDFs, etc ).
Our developers who check out these repositories have to wait an abnormally long time because of this for certain repos.
Has anyone else had this dilemma before? Am I going about it the right way by separating code from media? Here are some issues/worries I had:
If I migrate these into a media server then I'm afraid it might be a pain for the developer to use. Instead of making updates to one server he/she will have to now update two servers if they are doing both programming logic and media updates.
If I migrate these into a media server, I'll still have to revision control the media, no? So the developer would have to commit code updates and commit media updates.
How would the developer test locally? I could make my site use absolute urls, eg src="http://media.domain.com/site/blah/image.gif", but this wouldn't work locally. I assume I'd have to change my site templating to decide whether it's local/development or production and based on that, change the BASE_URL.
Is it worth all the trouble to do this? We deal with about 100-150 sites, not a dozen or so major sites and so we have around 100-150 repositories. We won't have the time or resources to change existing sites, and we can only implement this on brand new sites.
I would still have to keep scripts that generate media ( pdf generators ) and the generated media on the code repository, right? It would be a huge pain to update all those pdf generators to POST files to external media servers, and an extra pain taking caching into account.
I'd appreciate any insight into the questions I have regarding managing media and code.
First, yes, separating media and generated content (like the generated pdf) from the source control is a good idea.
That is because of:
disk space and checkout time (as you describe in your question)
the lack of CVS feature actually used by this kind of file (no diff, no merge, only label and branches)
That said, any transition of this kind is costly to put in place.
You need to separate the release management process (generate the right files at the right places) from the development process (getting from one or two referential the right material to develop/update your projects)
Binaries fall generally into two categories:
non-generated binaries:
They are best kept in an artifact repository (like Nexus for instance), under a label that would match the label used for the text sources in a VCS
generated binaries (like your pdf):
ideally, they shouldn't be kept in any repository, but only generated during the release management phase in order to be deployed.
We have an application at work which is web-based and comes with a bundled web server (Apache tomcat), and is for network monitoring/patch management. It allows for personalisation, all sorts of rules, custom UI design using proprietary components and definition language, and even custom code to fire on events (based on Java).
I am in a team of several developers, each of who will be customising this app to meet various requirements. As it's a server app, not a codebase, what's the best way to setup a dev environment for >1 user?
If there is one single shared VM with this app, I don't know how good source control like TFS would work with this sort of system? I think also, developers working on various parts of the project may even need the same file at the same time (though TFS does do multiple check-outs).
What is the best way to develop against this sort of product? Bare in mind, even with personal VMs and an instance of the app, changes have to be merged to one central instance. Something keeps making me think about how app-virtualisation could help with this?
Thanks
If it is just an instance of Tomcat (even though it was bundled) couldn't you put the whole Tomcat directory and all of its subdirectories under source control? You just need to check in the non-binary parts, so exclude all the .jar, .exe, .tar.gz and .dll files when you check in. That's what I would do, unless I misunderstood your question.
I'm not familiar with the source control software that you mentioned. I have been using SVN (which is free) and TortoiseSVN as a client (also free). Just an option if your software can't support what I've suggested.
I'm trying to find a free software that would provide a web interface to a file system (so you can add / remove files / directories, possibly edit them). If possible, it should handle versioning (only simple things needed : back to previous versions), and user management.
Can you point me to anything like that ? thanks
Update1 : I'm looking for a solution that would work on unix (e.g. linux).
Update2 : something like a subversion web interface on an Apache server would do the trick, alas I couldn't find any user friendly subversion web interface, Do you ? Plus it shold allow users to create new content.
You want something that supports something called Web Distributed Authoring and Versioning (look up WebDAV). Apple's MobileMe does this, as does Subversion over httpd, as does MS Sharepoint.
In fact, if you just want WebDAV functionality for free, try out Subversion and Apache.
Have you looked at DropBox? It's a hosted solution (2GB for free). It has a web interface that allows you to do rollbacks/etc.
Which CMS is the most flexible and/or easily modifiable in the following ways:
Have multiple clients access the CMS with multiple users per client. And each client can control multiple sites.
Control the layout of created pages based on certain criteria. Criteria such as which
section/sub-section the user would like to put the page in. e.g. - if the section for the page chosen is Clothing->Womens->Shorts then only allow certain layouts to be chosen.
It would go something like this:
- The user creates a new page within the CMS
- They choose the section or subsection of the page
- Based on that selection, we control if they are allowed to use the chosen layout/template.
Reason for this is that we want to control the UI of the top level pages (where the user enters the site from). And, have less control on the lower nested pages.
2 very flexible Php based CMS frameworks are Drupal and Joomla. Both are built upon plugin architectures where you can customize you application by downloading, installing and configuring the appropriate plugins for things like blogs, forums, search indexing, RSS, storing & playing video etc...
Drupal refers to their plugins as Modules. There are thousands of modules available (over 700 in the Utilities category alone). Warning - the modules are version dependant and not all modules have been upgraded to run in the current production versions of Drupal so pay attention to the version support.
Joomla refers to their plugins as Extensions. At time of posting, they had over 4500 extensions available. I haven't used Joomla myself so I can't talk to it's quality or ease of use, but it does seem to be another very popular, flexible product.
I just found this post that compares 10 Java based opensource cms products. I don't know if you have a particular technology in mind, but if Java's your thing one of these might help you out.
http://blog.taragana.com/index.php/archive/top-10-java-content-management-software/
Have a look at Jahia (www.jahia.com) - java open source based cms. The features you are describing are indeed typical of "site factories" which is a main business case for that CMS.
read http://www.jahia.com/jahia/webdav/site/jahiacom/shared/products/Jahia%20Sitefactory_WhitePaper.pdf and test yourself the features with the online demo.
I'm using Jahia with Alfresco as document repository using Communitiy release (without Alfresco connector, not too easy but it's possible using REST).
It's really a good solution because with Jahia you could add some Java Spring dynamic modules.
i think Wordpress is one of the best content management system. that provides much better flexibility as compared to other CMS.