I've a very basic question which drives me nuts. I maintain my own little framework. I can configure the framework with a YAML/JSON/XML/whatever settings file. The framework uses also a cache (any of memcached/couchbase/whatever even file based caching if no caching server is installed).
So no I've the following problem: I like to cache my settings parsed from the settings file in the cache but I would like to define the cache type used for that in the settings file.
What would be a proper solution for this? I can't imagine how I should manage this which leeds me to the thought that I probably have a very basic design / architecture error in my framework. Is there any solution at all?
Well as my experience from Symfony1 and Symfony2 goes, cache as much as you can.
In their production environment everything is cached, so you would run into your problem that the cache type is described in the settings file which is itself cached.
The proper solution to this is: As in Symfony: Delete the cache in prod, once you made changes to settings.
For dev the settings are always re-read as you do not profile in debug, so ease of development is more important that bootstrap time.
I recommend splitting this like symfony did.
For prod your settings are seldomly changed so parsing a file that can be cached is wasted resources and speed is typically priority 1 in prod.
Edit: Your options regarding the order of bootstrapping:
Always read settings first then decide which cache you will need.
Use a settings configuration cache that is hard coded (e.g file based)
I recommend using option 2. Your framework is cache agnostic as this can be configured, which is good but for basic settings of your framework you simply do not need that. You don't want to setup different cache mechanisms like memcache, sql etc just for basic settings.
Symfony solves this by the most effective way, as it provides a default cache generation for settings and this is simply a php file. Thats all. When symfony loads settings it looks for a certain file to include, if it does not exist, symfony caches it by creating plain php and then reads it.
You can determine the file type from the file extension. Then you can read the cache type and create a cache. The cache should be a singleton.
For the creation of the cache I would use an abstract factory, which implementation is dependent on the file type. The appropriate implementation of the abstract factory then can read the settings file and create the right cache.
I need to update source files (pull and update from the repository) in my production server, run migrations, and regenerate cached assets.
Is there any mechanism in Symfony 2 to do this safely? Like putting the site into 'maintainance mode' (which should throw a 503) or something?
I've just found a Bundle for Symfony 2, which offers you 2 extra-commands in the console to put your application into maintenance mode.
Here you go: https://github.com/lexik/LexikMaintenanceBundle
I've been trying to decide how I would implement this. On one hand, Symfony2 provides decent prod caching, so if you're not destructively modifying your database schema (removing columns or tables, etc), you can probably get away with just changing the schema, deploying from your repo, then clearing your prod cache. That's how I handle things most of the time.
On the other hand, if you DO want to go into maintenance mode, you'll want a solution that has minimal load on the framework (ie, you probably don't want to fire up the kernel), or you're defeating the purpose anyway: taking the load off the framework while you muck with things.
If it were me, I'd probably write a simple maintenance script that just sets a 503 header, maybe serves up some static html (pregenerated from my site templates) and sends it back to the user, then use some conditional logic in my app.php to use that when I should be in maintenance mode. It's ugly, but it works.
Not sure how to go about this for a bigger site where a user could be in the middle of some kind of transaction (shopping for instance) but for a smaller site could you not just use a .htaccess file (the one in the web directory assuming that is your root) to redirect to some maintenance page instead of into app.php.
I can recommend using deployer (http://deployer.org/) to deploy your Symfony2 application. This way you dont need a maintenance page. The tool ships with a symfony2 and symfony3 template already included.
It generates your assets, warms up the cache and keeps track of your release directories. It's easy to roll back to a previous release also.
there is a "current"-symlink which always points to your current release directory. If a release deployment is complete this link updates to the newly created release directory.
Regarding doctrine migrations you need to write a custom task for that.
Please look at capifony http://capifony.org/
It has excellent support for Symfony2.
We developed the Drupal based portal. After the testing and deployment (in locally) the site was working perfectly. But when I move the site to the online server (hosting), the site was facing the memory execution limit problem.
It's expecting minimum 96MB but the hosting provider is not able to increase that much!! Is any other way to fix this issue?? Or in Australia any other hosting provider is giving this much memory limit?
In my experience, 96MB is a lot for a Drupal site to require. Look over the modules you have installed on the site and disable and uninstall anything you don't actually need. For example, disable the core Color and Comment modules (enabled by default in Drupal 6), if you're not using them. If you have module like Views UI, Beautytips UI, ImageCache UI, or Rules Administration UI intalled, disable them once you're done configuring everything.
If there are only specific pages that are requiring too much memory, try optimizing those pages. For example, if there are lots of nodes being displayed in a view, try adding a pager to the view, to split the content across multiple pages.
If you have custom modules, try separating out the administrative UI code into a separate modulename.admin.inc file, so it will only be loaded when needed. Heck, consider doing that for publicly contributed modules too, then consider posting patches to the issue queues of those modules.
UPDATE: You may want to consider VPS hosting next. There you'll have more control over the system you're running on.
UPDATE 2: Depending on the needs and features of your site, you may be able to reduce your site's memory footprint by installing the Boost module, which creates a flat-file version of your site.
Is there a good option for having more than one person developing a Wordpress application with a testing site.
The biggest hurdle that I have encountered are path issues when developing locally and integrating to a testing environment.
Does anyone have a good process for maintaining developer environment(s), keeping working content and links, and the code is maintained in source control?
To clarify, I would like to develop locally, and have a testing environment, and avoid path issues. I am open to other solutions, or ideas.
It comes down to three main concepts
Development environment should be as close to production as possible.
Use Source Control!
Automated Deployment Scripts Take out as much human error when deploying.
The development enviornment/process I prefer looks like this.
Dev/Local
SVN To Check Out Code Locally
Virtual Box running Ubuntu as a Solution for LAMP Environment or XAMPP
Deploy Scripts (Script Automation e.g. NAnt/Ant) For Staging / QA
Module Development
Theme Development
Etc
QA
Initial Content Setup / QA
After Initial Development Staging is Used Less
Production
Live Content Entry
Blogging Etc
As for path issues after initial content development path issues become less relevant, as most content is performed live. If a backup of production is used to create a dev site, SQL scripts and manually changes can be used as necessary. Also switching to using a Virtual Box solution helps ensure everything is in root. But the answer by FractalizeR does help.
May be I don't get the problem in a whole, but what is the problem of putting the whole source code of WordPress into version control, check it out to a single test server for tests?
If you have problems with site names, force your developers to check out to their machines and store it under www.yourwpdomain.local (mind the .local part). They can use DNS or simple hosts file to resolve .local domain address into 127.0.0.1. Apache setup is pretty straightforward.
The rule is Separation of Concerns. You should not place your compiled components like DLLs, EXEs, or data of a system in source control. Wordpress is included in this context for two reasons: 1. the site is stored in the database. 2. The database and the site had better be on a nightly backup schedule. Would you ever need to restore the db or WP from Git? Heck no! Additionally, any WP customization should be placed in child themes, that will be included in source control. The parent theme? NO WAY! Never customize the parent theme in WP. If you are making changes to your base Wordpress site and\or parent theme, then you are at risk of losing your customization when Wordpress or the theme is updated.
From my experience, one of the bigger problems we come across during our webdevelopment process is keeping different setups updated and secure across different servers.
My company has it's own CMS which is currently installed across 100+ servers. At the moment, we use a hack-ish FTP-based approach, combined with upgrade scripts at specific locations to upgrade all of our CMS setups. Efficiently managing these setups becomes increasingly difficult and risky when there are several custom modules involved.
What is the best way to keep multiple setups of a web application secure and up-to-date?
How do you do it?
Are there any specific tips regarding modularity in applications, in order to maintain flexibility towards our clients, but still being able to efficiently manage multiple "branches" of an application?
Some contextual information: we mainly develop on the LAMP-stack. One of the main factors that helps us sell our CMS is that we can plugin pretty much anything our client wants. This can very from 10 to to 10.000 lines of custom code.
A lot of custom work consists of very small pieces of code; managing all these small pieces of code in Subversion seems quite tedious and inefficient to me (since we deliver around 2 websites every week, this would result in a lot of branches).
If there is something I am overlooking, I'd love to hear it from you.
Thanks in advance.
Roundup: first of all, thanks for all of your answers. All of these are really helpful.
I will most likely use a SVN-based approach, which makes benlumley's solution closest to what I will use. Since the answer to this question might differ in other usecases, I will accept the answer with the most votes at the end of the run.
Please examine the answers and vote for the ones that you think have the most added value.
I think using a version control system and "branching" the part of the codes that you have to modify could turn out to be the best approach in terms of robustness and efficiency.
A distributed version system could be best suited to your needs, since it would allow you to update your "core" features seamlessly on different "branches" while keeping some changes local if need be.
Edit: I'm pretty sure that keeping all that up to date with a distributed version system would be far less tedious than what you seem to expect : you can keep the changes you are sure you're never going to need elsewhere local, and the distributed aspect means each of your deployed application is actually independent from the others and only the fix you mean to propagate will propagate.
If customizing your application involves changing many little pieces of code, this may be a sign that your application's design is flawed. Your application should have a set of stable core code, extensibility points for custom libraries to plug into, the ability to change appearance using templates, and the ability to change behavior and install plugins using configuration files. In this way, you don't need a separate SVN branch for every client. Rather, keep the core code and extension plugin libraries in source control as normal. In another repository, create a folder for each client and keep all their templates and configuration files there.
For now, creating SVN branches may be the only solution that helps you keep your sanity. In your current state, it's almost inevitable that you'll make a mistake and mess up a client's site. At least with branches you are guaranteed to have a stable code base for each client. The only gotcha with SVN branches is if you move or rename a file in a branch, it's impossible to merge that change back down to the trunk (you'd have to do it manually).
Good luck!
EDIT: For an example of a well-designed application using all the principles I outlined above, see Magento E-Commerce. Magento is the most powerful, extensible and easy to customize web application I've worked with so far.
I may be wrong, but it seems to me what Aron is after is not version control. Versioning is great, and I'm sure they're using it already, but for managing updates on hundreds of customized installations, you need something else.
I'm thinking something along the lines of a purpose-built package system. You'll want every version of a module to keep track of its individual dependencies and 'guaranteed compatibilities', and use this information to automatically update only the 'safe' modules.
E.g. let's say you've built a new version 3 of your 'Wiki' module. You want to propagate the new version to all the servers running your application, but you've made changes to one of the interfaces within the Wiki module since version 2. Now, for all default installations, that is no problem, but it would break installations with custom extensions on top of the old interface. A well-planned package system would take care of this.
To address the security question, you should look into using digital signatures on your patches. There are lots of good libraries available for public-key-based signatures, so just go with whatever seems to be the standard for your chosen platform.
Not sure whether someone's said this, there are a lot of long responses here, and I've not read them all.
I think a better approach to your version control would be to have your CMS sat on its own in its own repository and each project in its own. (or, all of these could be subfolders within one repo i guess)
You can then use its trunk (or a specific branch/tag if you prefer) as an svn:external in each project that requires it. This way, any updates you make to the CMS can be committed back to its repository, and will be pulled into other projects as and when they are svn updated (or the external is svn:switch 'ed).
As part of making this easier, you will need to make sure the CMS and the custom functionality sit in different folders, so that svn externals works properly.
IE:
project
project/cms <-- cms here, via svn external
project/lib <-- custom bits here
project/www <-- folder to point apache/iis at
(you could have cms and lib under the www folder if needed)
This will let you branch/tag each project as you wish. You can also switch the svn:external location on a per branch/tag basis.
In terms of getting changes live, I'd suggest that you immediately get rid of ftp and use rsync or svn checkout/exports. Both work well, the choice is up to you.
I've got most experience with the rsync route, rsyncing an svn export to the server. If you go down this route, write some shell scripts, and you can create a test shell script to show you the files it will upload without uploading them as well, using the -n flag. I generally use a pair of scripts for each environment - one a test, and one to actually do it.
Shared key authentication so you don't need a password to send uploads up may also be useful, depending on how secure the server to be given the access is.
You could also maintain another shell script for doing bulk upgrades, which simply calls the relevant shell script for each project you want to upgrade.
Have you looked at Drupal? No, not to deploy and replace what you have, but to see how they handle customizations and site-specific modules?
Basically, there's a "sites" folder which has a directory for every site you're hosting. Within each folder is a separate settings.php which allows you to specify a different database. Finally, you can (optionally) have "themes" and "modules" folders within sites.
This allows you to do site-specific customizations of particular modules and limit certain modules to those sites. As a result, you end up with a site that the vast majority of everything is perfectly identical and only the differences get duplicated. Combine that with the way it handles upgrades and updates and you might have a viable model.
Build into the code a self-updating process.
It will check for updates and run them when/where/how you have configured it for the client.
You will have to create some sort of a list of modules (custom or not) that need to be tested with the new build prior to roll-out. When deploying an update you will have to ensure these are tested and integrated correctly. Hopefully your design can handle this.
Updates are ideally a few key steps.
a) Backup so you can back out. You should be able to back out
the entire update at any time. So,
that means creating a local archive
of the application and database
first.
b) Update Monitoring Process - Have the CMS system phone home to look for a new build.
c) Schedule Update on availability - Chances are you don't want the update to run the second it is available. This means you will have to create a cron/agent of some kind to do the system update automatically in the middle of the night. You can also consider client requirements to update on weekends, or on specific days. You can also stagger rolling out your updates so you don't update 1000 clients in 1 day and get tech support hell. Staggered roll-out of some kind might be beneficial for you.
d) Add maintenance mode to update the site -- Kick the site into maintenance mode.
e) SVN checkout or downloadable packages -- ideally you can deploy via svn checkout, and if not, setup your server to deliver svn generated packages into an archive that can be deployed on client sites.
f) Deploy DB Scripts - Backup the databases, update them, populate them
g) Update site code - All this work for one step.
h) Run some tests on it. If your code has self-tests built in, it would be ideal.
Here's what I do...
Client-specific include path
Shared, common code is in shared/current_version/lib/
Site specific code is in clients/foo.com/lib
The include path is set to include from the clients/foo.com/lib, and then share/lib
The whole thing is in a version control system
This ensures that the code uses shared files wherever possible, but if I need to override a particular class or file for some reason, I can write a client specific version in their folder.
Alias common files
My virtual host configuration will contain a line like
Alias /common <path>/shared/current_version/public_html/common
Which allows common UI elements, icons, etc to be shared across projects
Tag the common code with each site release
After each site release, I tag the common code by creating a branch to effectively freeze that point in time. This allows me to deploy /shared/version_xyz/ to the live server. Then I can have a virtual host use a particular version of the common files, or leave it pointing at the current_version if I want it to pick up the latest updates.
Have you looked at tools such as Puppet (for system administration incl. app deployment) or Capistrano (deployment of apps in RubyOnRails but not limited to these)?
One option would be to set up a read-only version control system (Subversion). You could integrate access to the repository into your CMS and invoke the updates through a menu, or automatically if you do not want the user to have a choice about an update (could be critical). Using a version control system would also allow you to keep different branches easily
As people have already mentioned that using version control (I prefer Subversion due to functionality) and branching would be the best option. Another open source software available on sourceforge called cruisecontrol. Its amazing, you configure cruisecontrol with subversion in sach a way that any code modification or new code added in serversion, Cruise control will know automatically and will do build for you. It will save your hell of time.
I have done the same way in my company. we have four projects and have to deploy that project on different servers. I have setup cruiseconrol in such a way that any modification in code base triggers automatic build. and another script will deploy that build on the server. your are good to go.
If you use a LAMP stack I would definitely turn the solutions files into a package of your distribution and use it for propagate changes. I recommend for that matter Redhat/Fedora because of RPM and it's what I have experience on. Anyway you can use any Debian based distribution too.
Sometime ago I made a LAMP solution for managing an ISP hosting servers. They had multiple servers to take care of web hosting and I needed a way to deploy the changes of my manager, because every machine was self-contained and had a online manager. I made a RPM package containing the solution files (php mostly) and some deploying scripts that runned with the RPM.
For automated updating we had our own RPM repository set on every server in yum.conf. I set an crontab job to update the servers daily with the latest RPMs from that trusted repository.
Trustiness can be achieve too because you can use trust settings in the RPM packages, like signing them with your public key file and accepting only signed packages.
Hm could it be an idea to add configuration files? You wrote that a lot of small script are doing something. Now if you'd build them into the sources and steered them with configuration files shouldn't that "ease" that?
On the other hand having branches for every customer looks like an exponential growth to me. And how would you "know" which areas you've done something and do not forget to "make" changes in all other branches also. That looks quite ugly to me.
It seems a combination of revision controls, configuration options and/or deployment receipts seems to be a "good" idea.....
With that many variations on your core software, I think you really need a version control system to stay on top of pushing updates from the trunk to the individual client sites.
So if you think Subversion would be tedious, you've got a good sense for what the pain points will be... Personally, I wouldn't recommend Subversion for this, since it's not really that good at managing & tracking branches. Although benlumley's suggestion to use externals for your core software is a good one, this breaks down if you need to tweak the core code for your client sites.
Look into Git for version control, it's built for branching, and it's fast.
Check out Capistrano for managing your deployments. It's a ruby script, often used with Rails, but it can be used for all sorts of file management on remote servers, even non-ruby sites. It can get the content to the remote end through various stragegies including ftp, scp, rsync, as well as automatically checking out the latest version from your repository. The nice features it provides include callback hooks for every step of the deploy process (e.g. so you can copy your site-specific configuration files which might not be in version control), and a release log system--done through symlinks--so you can quickly roll back to a previous release in case of trouble.
I'd recommend a config file with the list of branches and their hosted location, then run through that with a script that checks out each branch in turn and uploads the latest changes. This could be cron'd to do nightly updates automatically.