I have Moodle running on a WAMP setup on Windows 2003. After sufficient testing, I would like to setup a separate server as a Moodle development server on which I can experiment without affecting the production server once people start taking courses. My IT department said that they would duplicate the server, so that I would have an exact copy of the 2003 instance.
I know that such a duplication will require changes for Moodle to work - anything referencing the server name, such as Moodle's config.php, and possibly some things in php and apache that reference the server as well; iis email also.
As a beginner in enterprise development, and working alone on this (there are no developers here to ask), I would like to ask what the best setup for a development-to-production server is. Should I take the duplicated server, make changes...and then, how do I move my updates from one to the other most efficiently?
Thank you.
A Moodle installation comprises three things:
A. the Moodle code.
B. the database
C. the moodledata folder.
So, when you backup or clone a site, it is these three things you are talking about copying.
As a developer, you are most interested in the code.
When you have a new version of the code to deploy (either downloaded from Moodle.org, or changes you have mode) the normal procedure is:
1. Update the code on the server (A -> A').
2. Visit the admin page of the Moodle site, so Moodle can self-update the database structure (B) and moodledata (C) if necessary.
Except that if you are deploying to an important production server, the procedure looks more like:
1. Clone your entire moodle site (A + B + C) to a test server.
2. Upgrade the code on the test server, and go to the admin page to complete the upgrade.
3. Test what you have on the testing server. If all is well ...
4. Take another full copy of the production server as a backup.
5. pgrade the code on the production server, and go to the admin page to complete the upgrade.
6. Double-check that everything is still working.
So, anyway, for a serious production environment you certainly need the production server and a test server, but when doing development I think it is best to do your development on some other machine, say your desktop machine. For development you just do a new install of the code, and create whatever test data you need. That way, it is not a big deal if you screw up badly, and end up having to wipe it and start again. When you think you have everything working, then you move it to the test server for testing against a copy of the real server, and finally put it into production.
Another reason to do this is that your real database has a copy of a lot of student's personal information. So, if you are developing on your laptop, it is best not to have a copy of all that data there.
Also, you can quickly and easily set up different development areas if you need to work on different things at the same time.
Also, if you are doing development in a personal space, that will work better when there is more than one developer.
Finally, I strongly recommend you get into a version control system for managing your source code. These days, the best solution is probably git. Development:Tracking_Moodle_CVS_with_git
A. the Moodle code.
B. the database
C. the moodledata folder.
So, when you backup or clone a site, it is these three things you are talking about copying.
As a developer, you are most interested in the code.
When you have a new version of the code to deploy (either downloaded from Moodle.org, or changes you have mode) the normal procedure is:
1. Update the code on the server (A -> A').
2. Visit the admin page of the Moodle site, so Moodle can self-update the database structure (B) and moodledata (C) if necessary.
Except that if you are deploying to an important production server, the procedure looks more like:
1. Clone your entire moodle site (A + B + C) to a test server.
2. Upgrade the code on the test server, and go to the admin page to complete the upgrade.
3. Test what you have on the testing server. If all is well ...
4. Take another full copy of the production server as a backup.
5. pgrade the code on the production server, and go to the admin page to complete the upgrade.
6. Double-check that everything is still working.
So, anyway, for a serious production environment you certainly need the production server and a test server, but when doing development I think it is best to do your development on some other machine, say your desktop machine. For development you just do a new install of the code, and create whatever test data you need. That way, it is not a big deal if you screw up badly, and end up having to wipe it and start again. When you think you have everything working, then you move it to the test server for testing against a copy of the real server, and finally put it into production.
Another reason to do this is that your real database has a copy of a lot of student's personal information. So, if you are developing on your laptop, it is best not to have a copy of all that data there.
Also, you can quickly and easily set up different development areas if you need to work on different things at the same time.
Also, if you are doing development in a personal space, that will work better when there is more than one developer.
Finally, I strongly recommend you get into a version control system for managing your source code. These days, the best solution is probably git. Development:Tracking_Moodle_CVS_with_git
Tim's plan is excellent. A couple extra notes:
Email routing: On the "test server", for completeness you need to run cron. Cron sends emails (and perhaps in the future other bits of moodle will too). So you must setup an email server on the test server that re-routes all email ouput to a single test account.
This allows you to test changes to email code too
Backends: If your Moodle reads (and maybe writes) from a backend, you'll want to clone that too.
Clearly identify every version that gets deployed: Your workflow when deploying must generate a snapshot of the code, and somehow log exactly when that snapshot got installed. Knowing exactly what and when is very important when find you have a bug that subtly corrupts data, and may be your only way to recover.
There are 2 good ways of doing this: putting tags on the exact commit you are deploying (based on your version control system) or deploying using installation packages (dpkg, rpm... on Windows msi may be workable). The Catalyst team has done a great job in creating some dpkg templates. People interested in rpm packages can probably look at my spec file in the moodle-xs repo. MSI packaging... did Dan Marsden say he had a nice MSI packaging technique?
One corollary is to this is never ever deploy code that has not been formally committed to a version control system.
Automated deployment: Hitting the 'admin' page is not a good deployment technique for live servers. A real user may win the race with you, you may have many admins hitting it simultaneously; the whole process is so racey it's not funny.
The sane approach is to close HTTP access before upgrading the code and to instead control the upgrade using the 'cliupgrade' patches; that gives you a commandline script that will complete installations and upgrades. After upgrade, put moodle in "maintenance mode", open HTTP access, visit it as admin to see that all is right, and then disable maintenance mode.
Within the automated deployment workflow, it is a good idea to snapshot your database & moodledata if you can, in case something goes wrong in the upgrade process (and so that you can quickly dig up in case of bug reports after the deployment).