While I really prefer to use tools like this for deployment, I understand that not everyone wants to mess with standalone programs and configuration files. I’ve been asked before about Cake-specific deployment techniques, so I figure the easiest way is to see about adding a task to the Cake console. Let’s call this ‘cake deploy’.

As I explained on the mailing list I am looking for opinions on what sort of things should be part of the ‘cake deploy’ task. Right now, my thoughts are as follows:

• cake deploy config

- setup and edit configuration parameters. Initially I thought of setting things like transport method (ssh, ftp), logins and passwords, remote location, source directory, and destination directory. The configuration file would be stored locally in APP/config

• cake deploy - seems pretty self-explanatory to me.

In the RFC thread on the CakePHP mailing list, someone mentioned they’d like to see rsync, but I’m trying to avoid having to external programs required to make the deployment work. Or, at least, use as few as possible. Anyhow, if you have any thoughts on this feel free to add them to the comments.

One idea is to move the functionality to the AppModel. That works, but it is a dirty solution. The AppModel should contain generic functionality relevant for all models, and not functionality specific to only two models.

Another idea is to move the functionality into a class in the vendors folder and to load it with App::import(). That works fine, but if you compare this solution with elements and helpers for reusing view functionality, and with components for reusing controller functionality, it is a bit strange there is no “native” solution for models (sure, there are behaviors, but they are not designed for the kind of code reuse I described above).

Hence I think it would be useful to have model “components”, which could be realized in the same way as controller components are realized. For example:

class Example extends AppModel { public $components = array('X'); public function doSomething() { ... $this->X->doSomethingElse(); // using model component ... }
}

In the longer term it would even make sense to have a unified “components” concept to replace the current concepts of components and helpers. But well, we will see what the future brings ;-)

Anyhow, anyone who uses CakePHP or wants to help out can definitely get involved in the process by:

• Entering bugs into CakePHP’s trac if they don’t see them in there
• Contributing tests and/or patches for existing bugs
• Testing out the bleeding-edge versions of CakePHP that you can get from the SVN repository

There has been a lot of debate on the mailing list about both the direction of the project and the attitude of people on the mailing list. Well, as one of the people who gets to be involved in both sides (albeit a minor role in terms of contributing code) I can tell you that the project will continue moving forward, building on all the traction CakePHP has gotten. Maybe 1.2 has dragged on for a while, but isn’t that just a number anyway? Would people be reacting if it was Cake 1.7.2 or something like that?

What people don’t always see is the amount of work that goes into CakePHP by developers. Every morning when I log into my account on my MacBook, I update my copy of CakePHP from SVN. 99.999% of the time there is an update. These days, tests are being written like crazy and Tim’s awesome work in creating code coverage information and those things can only help the project as a whole get better. These are exciting times for anyone connected to the project, no doubt about that. No amount of CakePHP haters (you know who you are) are going to change that.

Secondly, people have to understand that a mailing list full of a lot of technical, highly-skilled people is not a friendly place for beginners. Sad, but true. I have answered many questions on the mailing list, some of them properly and some of them, well, let’s just say my nickname of GrumpyCanuck has been well-placed. Can we all be civil? Probably not. Should we be civil? Maybe. I think anyone who doesn’t understand the dynamics of the CakePHP list itself should go and read this. Forewarned is forearmed.

Anyway, I think this is a good opportunity to think about failing tests (with tests I primarily mean unit tests).

Even though “failing tests” may sound quite negative, this is not the case, at least if you practice test driven development (or a similar approach). There, failing tests are an integral part of the process. You start with a failing test, and then you implement the functionality so that the test no longer fails. Or if you make a change, and you break something by accident, then a failing test informs you about it. So, a failing test is quite positive.

On the other hand, failing tests also have a dark side.

The longer you wait to fix them, the higher the “costs”. If you fix a failing test immediately, then the costs are almost zero: you know what you changed, and so you can easily fix it. But if you wait a while, then the code is no longer present in your mind and it takes much more effort to fix the failing test. A side effect of this waiting is that it encourages others to do the same. If X doesn’t fix the tests he has broken, why should I care whether my tests run? As another side effect it may undermine the motivation of bug reporters to contribute tests if they see the project members don’t care about tests…

A special “behavior” of failing tests is that they don’t tell you whether they fail because of an incorrect test case or a bug in the code you test (in practice, this is sometimes obvious, sometimes not, depending on various factors). And they don’t tell you whether they only fail in your environment or everywhere. So, this means, if I run your tests and some of them fail, then all I can say may be: test X fails in my environment (the reason for saying “in my environment” is that I assume you don’t give me broken code, i.e. code with tests you know are failing). As it is an environment-specific issue, I will inform you about it, so it can get fixed. But if you provide broken code, then everyone using it will bother you with the same issue, at least theoretically ;-)

I think it is obvious what helps to deal with those dark sides: don’t provide code with tests you know are failing, it’s that simple!

I hope it wasn’t too confusing, and sorry about the rant at the beginning, but sometimes it’s necessary to vent one’s anger ;-)