This is about my server setup and the way how the IDE, test environment and version control (Subversion) work together. Image first, explanation afterwards…
- The webserver Apache links the URL of my localhost to the ‘cms’ directory. (Actually it is “http://localhost/cms/” in my case, because I use some other stuff on the root level.
- The ‘cms’ subdirectory of my local web presence is a soft link to a dummy installation of Typo3 in the same directory. The link depends on the Typo3 version I just use. Thus I can switch from e.g. 4.5.32 (dotted line) to 4.5.37 (solid line) just by redefining the soft link.
- The Typo3 dummy installation contains a ‘typo3_src’ soft link to the Typo3 core system, which is located at ‘/opt/typo3_src_4.5.xx’ (where ‘xx’ is ’32’ or ’37’ in this case). This is recommended by the Typo3 installation guide in order to split the Typo3 installation into the local system for one web presence and the core. It’s not 100% necessary in this configuration, but it is more flexible, if I want to use the core for some other sites on this server as well.
- All 4.5.xx versions of Typo3 use the same DB-connection to a local MySQL database. As long as the DB structure does not change between patches, this is valid. Thus the content of the web site stays the same, no matter if I use the 4.5.32 or 4.5.37 link at 2.
- No matter if I use the 4.5.32 or 4.5.37 installation, I just want to make sure that my developed extension is exactly the same in both installations. And in order to update the extension with the latest developed version as easy as possible, I want to have full access rights (esp. write) to the extension directory. Thus I use a central ‘.sandbox’ directory inside my Eclipse workspace, which holds the last deployment. Both Typo3 installations link the typo3conf/ext/csevents directory to this sandbox directory. Now all access rights inside the Typo3 installation stay on wwwrun level and I have full access on the sandbox directory, which is located inside my home directory (underneath ‘workspace’). Eclipse allows to generate all subdirectories despite of ‘.metadata’, thus this is a valid directory.
- Inside the Eclipse workspace there is a project directory ‘csevents’ holding the complete Eclipse project with all meta data, additional project data and resources. The ‘.sandbox’ directory stores the deployed version of the extension only. Thus there is no meta data, no additional files etc. The ‘deployment’ is a simple copy job performed by an Ant script. We will have a look at this ant script in the next post. This structure and the deployment process separate the development version from the current testing version, thus I can test on the last deployed version while I’m already changing the code in the development environment.
- Finally there is a Subversion connection managed by Eclipse to store all project changes directly to the version control system. My policy is: Check in exactly when (and only when) all tests are successful.
- Testing and development can be done separately. The Typo3 extension directory (i.e. the ‘.sandbox’) gets the source code only. There won’t be any SVN files, Eclipse project files or any other administrative development stuff. Thus this is a copy of the “real world”. Good.
- It’s well prepared to use it for “Deployment from SVN” later on, if I need to switch back to an older version of the extension in the Typo3 environment, but don’t want to change my current development environment on Eclipse. This would be a direct copy from Subversion to the ‘.sandbox’ directory bypassing Eclipse’s workspace development directory. Very Good.
- I can use multiple Typo3 versions for testing (in this case 4.5.32 and 4.5.37). I can access them directly (‘http://localhost/dummy-4.5.32/’) or the current one simply by using the ‘http://localhost/cms/’ shortcut.
- I don’t have to build up the content for each installation separatly, because all installations use the same DB connection (as long as table structures are not changed).
Step 6 – the “deployment” from the Eclipse workspace to the sandbox – is the most important one, because it’s used most frequently while developing / testing. Thus it is very important to make this step reliable, fast and easy to use. Because it’s just a lightweight “build” process, let’s use the one-and-only-build-tool-for-Eclipse. That is ant. Yep, I added a very simple ant build script to the project. The only thing it does, is to copy all relevant files from my Eclipse workspace to the ‘.sandbox’ folder. Because this is now the default build script, I can just use Eclipse’ build hotkey (Ctrl+B) to copy all files to the test environment. Simple, fast, easy to remember, efficient. Good! (And I use this instead of a ‘bash cp’, because I am lazy!)
You could ask: Is it the correct way, just to copy the files into the Typo3 extension folder? Isn’t it better to uninstall and re-install the complete extension inside Typo3 ExtManager? The answer is: Yes and no.
If you do severe changes to your extension (adding DB tables, columns etc.), it’s always recommended to use the official extension installation process via the Typo3 backend. I’m sure, somebody can build an ant script for this as well, but I haven’t done this ’til now, because there was no reason to do so.
As long as you do just some simple PHP programming inside your source code, a simple copy process is just enough. You don’t even need to reset the Typo3 caches. While you are working on a new feature or on reengineering (like I do here), you spent much more than 90% of your time on writing just PHP code. Therefor this is a very simple and efficient solution.
So please have a look at the next post to find out about the ant script I use to do the PHP “build” process (just by copying files).