AMO:v4/Planning/Strategy

The scuttlebutt around the AMO project is that we should move to either Kohana or Django. That call hasn't been officially made but I've been thinking about it and my current opinion leans towards Kohana because I think it will be easier to create sharable libraries and swap pieces of code out. Since Kohana and CakePHP are both PHP, we can replace sections of code based on the location and function of it rather than the entire MVC stack for an object. For example, we can focus on converting the files in the components directory rather than trying to convert the MVC for collections. Using Django we could try to integrate the two further to reduce that, like getting the controllers to talk to the PHP models through some abstraction but that feels like a lot of work for what we'd get. I think more code can be reused with Kohana and it will take less time to finish the plan. Please give me input if you disagree

All that said, my internet has been down all morning which has given me some time to come up with a high level plan if we go with Kohana. As always, I'm glad to have feedback/suggestions. Plan of attack if we use Kohana:

I've talked about it with a few people, but it might be time to mention it publicly: I'd like to decrease the time it takes for our release cycles. This will relieve a lot of the stress of our pushes on IT (little to nothing for them to do), QA (far less for them to QA all at once), L10n (their stuff could get updated a bunch), webdev (less to do all at once, getting code out sooner makes people happy), Marketing (faster turn around time on ideas, faster feedback from users), Security (bug fixes live sooner), etc. To get everyone on board this would mean better test coverage and an automated continuous integration system. If we could do that, I think figuring out a button that says "push to live site" wouldn't be too hard. A basic strategy focusing on biggest wins first:

• There are a lot of opinions on AMO:v4/Planning/Goals. We need to decide on what we're using for:
  • DBAL:
    • Does something exist in a sharable library that meets the needs on that page?
  • Views:
    • Will built in kohana views work?
  • Testing:
    • Simpletest appears to be stagnate and doesn't support everything jbalogh wants. PHPUnit is the most popular I think and has some continuous integration features. Opinions on using phpunit here?
  • Off-line work queue:
    • I haven't used any of these. Opinions? We'll ask IT too.
  • Codename:
    • I like all the options. <3
  • Logging:
    • Will built-in kohana be good enough or is there a shareable library?
  • Form validation:
    • Will built in kohana stuff work or is there a shareable library?

If we can't decide via IRC, phone, etc. We can make the above decisions at the AMO Onsite. Once those choices are made:

• Setup basic Kohana, get it talking to the db
• Setup a testing infrastructure for kohana. All code following should have reasonable test coverage.
• Integrate logging library or confirm we can use the built in.
• [optional] Setup our off-line work queue. If we don't do this now, we should be adding grepable comments to replace code with it later. If it's not a lot of work, we should be doing it now or we can even have it setup before we even start on AMO:v4.
• Integrate DBAL or confirm we can use the built in.
• Build a layer for L10n CRUD. This is a good candidate for a well documented API/REST thing, but that's not required. If we can abstract this out we shouldn't care how it's stored in the db and we can look at better ways in the future without modifying application code. If this can be a shareable library, more power to us.
• Integrate view library or confirm we can use the built in. We should have a plan for templates, escaping and utf-8 stuff.
• Similarly, let's talk about some generic JSON/AJAX stuff that we can do both in the controllers and views to keep that code simple/shared.
• Integrate form library or confirm we can use the built in.
• At this point we should have a pretty kick ass generic framework. We should put it on a tag somewhere to make it easy to build high-capacity sites later.
• Integrate generic and/or high level stuff that we need. I'm talking about stuff in bootstrap.php, extra functions in the setup files, stuff like that. There are a half dozen functions that are global and used all over or at the start of sessions that we'll either need to migrate or ensure a kohana equivalent exists. We might even want to do some of this before we tag our generic framework - stuff like locale detection, ___(), etc.
• Setup most models with CRUD and basic "special" functions we're using. We don't need 100% transition here but it should be the majority. Tests should be migrated or written as this code is. This includes converting high level stuff from AppModel.
• New code from this point on should use the new model code.
• Replace majority of components with kohana files using the new db code. Replace controllers as necessary, but focus on components.
• Replace majority of controllers with kohana files. This includes AppController stuff.
• Replace majority of view elements with kohana files. We might need to replace views here also, but focus on elements.
• Replace majority of views with kohana views. As we do this look for sections that could become elements and convert them.
  • If the non-amo2009 stuff is not gone already, it shouldn't survive past this point.
• Review any code that isn't converted. If it makes sense to convert it, do it. If it doesn't, remove it as useless (FAMO! ;)
• Evaluate our testing coverage and QA strategy, etc. If it's good enough: build continuous integration infrastructure, make a "push" button, be happy.

The whole section on replace MVC stuff isn't going to be cut and dried and there will be a lot of that going on in parallel. I think it makes sense to focus on parts of it when possible though and that's why I put it in that order. We can break down more specific sections if we need to (like, what order to do the controllers in) when we get to it.