How long do you normally test an update for Zend Framework before pushing it out into a productions project. We can break this question up into minor updates 1.6.0 -> 1.6.1 or maybe a major update 1.6.2 -> 1.7.0. Obviously you don't release it if it add bugs to your code.
Also, as with most other server software updates normally people have a window of time they like to wait and watch the community before even attempting an update on a development environment. How long do you even wait to start the process?
It seems like the best method would be to have a comprehensive set of tests that exercised all the functionality in your application. With a good method for testing it seems like you could push it into production pretty quickly.
Another simple thing you can do to help you make your decision would be to simply do a diff against the repository to see what changes where applied to any modules that you use. If there where no changes, then upgrading shouldn't make any difference. If something underwent a major re-write, you would probably want to investigate a lot deeper.
I'll often jump through update releases (1.7.1 -> 1.7.2) without much hesitation. When the minors roll in, it's another bag of tricks though. For example, there were a lot of changes with Zend's file upload elements, and Zend form in between 1.5, 1.6 and 1.7.
Whether or not I even move on a new release depends on what's been done. Checking the update lists provided is pretty important for deciding on whether or not to go.
As for timing, it varies. There's no set in stone process.
Finding "what breaks" is quickly accomplished with the unit tests. But, who really has a full set of unit tests for their application, right? ;)
Using unit testing will help catch some of the deltas. Zend Framework now comes with Zend_Test to make testing applications a bit easier. I updgrade between projects (so new projects that are coming up will get the latest version).
Related
We have a huge code-base (I mean huge, about 2M+ lines) in PHP. I would like to know how you guys managed to integrate composer in this kind of situation.
Specially when the code cannot be decoupled in little projects (Right now) because of the complexity (Even mixed with legacy code) and it's being hold in the same SVN repository.
Why should I be confident in the quality of the composer/packagist libraries?
What happens if packagist goes down?
What should I do if my vendor repository goes down (Github/Bitbucket/Whatever)?
What happens if some of my vendors decide to delete their library?
What if they've been hacked and set the next version tag empty?
I know that this possible problems could be over-passed in one way or another. But the fact that the life of a lot people could be depending on this makes me feel a bit crazy with this kind of decision.
What do you think? What are my best options?
For the first point - if you have legacy, 2M+ tighthly-coupled codebase, common open source projects quality shouldn't bother you ;).
For the rest - you can use staging to build your project together with dependencies and then build a full package there (by that I mean all the dependencies downloaded and bundles). Of course you will still be dependent on external packages on your development cycle, but not in deployment/production. Whenever package goes down, you have time and possibility to replace it.
Composer is a really great tool for bundling yor project together with dependencies, so it's both the answer to question "how to use external dependencies" and also to "how to be independent from them", you only need to specify the point, at which you want to bring this independency into your project.
I think that you should develop with external dependencies in mind, lowering your code base as much as possible and not put these problems on your devs shoulders, they want to use code, libraries, play with tiem... then, somewhere in your deployment process, bundle it all together (staging is a good place). Even if your dependencies will disappear and you will have to spend your development time to replace them:
It will probably still cost you less than handling all on your own.
We're considering using a CI server soon.
From my reading, I've found that Sismo and Hudson were available for PHP project.
Considering that we're actually using GIT and PHPUnit, what are the big difference between Hudson and Sismo that we should know in order to make the best choice for our situation ?
Thanks
The language match is not key in your hunt for the best CI server; it's all the features around:
source control
concurrent build
trigger build
notification
Even for simple project, Jenkins (the new name for Hudson) is easy to use and quick to install. Then it is really easy to scale Jenkins up by adding more nodes (satellite machine that can execute build) when you need to. Also Jenkins has hundreds of plugin for numerous task.
Have a look at Bamboo, Jenkins, TeamCity, and CruiseControl Features to compare some of the features of the big names (you might actually want to consider Bamboo, TeamCity or Cruise Control over Jenkins)
I would lean towards Sismo since it matches the language of the project you are developing (PHP) and can be ran from just a single PHP and config file. Then you don't have to deal with having a java environment just for Hudson.
There is a really good php-integration for Jenkins by the phpunit inventor Sebastian Bergmann. You should really have a look at it.
As far as I see the biggest downside of Sismo is, that is not a "real" CI server, but more a build-and-report-environment, because you need to trigger the builds yourself (or let something trigger it).
I'll preface this by saying that I haven't used sismo.
We use Hudson with applications being built & tested in both Java and PHP. It has a nice plugin system, and getting it up and running on a centOS box took about 15 minutes yesterday. (We had to move it from one box to another).
For PHP Hudson integrates with both PHPUnit and Selenium so we run both unit tests and functional tests against the same codebase. Hudson has a great 'one-click' plugin system that really lets you customize your installation.
One thing we had to get a plugin for was sending an email on every build whether successful or not. Hudson by default will only email when your build goes from good (tests pass) to bad, from bad to good, or repeatedly bad. This means it will not send an email for every build if 2 builds in a row were successful. The email plugin solves this but it was confusing to uncover that.
I am in the process of planning a custom web application which will be sold (not SaaS) and so will be required to be installed on different servers. Do you think it would be a bad/good idea to go with Symfony2 or Zend Framework.
I have to choose 1 and can't go with any other framework as I only have extensive knowledge with both of these. Despite my experience with Symfony2, I would still appreciate another opinion.
My main concerns are ease of install on servers and source code protection. Sadly, it would seem ZF already has this going for it in that you don't need 5.3 like Symfony2, and we have Zend Guard.
Any advice is welcome! I am looking to nurture and grow this app and I really want to be sure the first step is the right one.
The Symfony2 download page still says:
Be warned that Symfony 2.0 is not
stable yet; use it with caution
(current version is Beta 1).
So I would wait just a but for Symfony2.
I'm not sure what you mean by source code protection but there is no point in encoding any part of any of the two frameworks since they are both open source (and you should see if their licenses actually do permit that!).
Zend Framework 2 is still in the oven and for the looks of it, Symfony2 will be out of beta way before ZF2. If you can't wait, then use the one that you are most comfortable with. Otherwise, wait for Symfony2 to come out of beta and then wait a little bit more until they iron out it's bugs.
Now, about bundling the framework in your application, you are probably going to need to write an installer of sorts. You could first look at the "sandbox" version of Symfony to see how they did that. It's basically an unzip-it-and-it-works kind of install. No need to set anything up. That could give you some pointers.
Whatever you do, you'll need to write a minimum specs script that users can download and run to check whether their system has everything ready to run your app (check configs, php modules, etc, etc). See SlideShowPro Director for an example of such scripts.
Subjective answer: I'd go with ZF because that's what I know better, but having said that, performance wise I've had better results with Symfony. Apparently ZF2 will have see huge speed improvements.
This is more or less related to project management and also with every developer. How you guys handle this situation when you have developed many features on development site and all are tested by client and ready to go live.
These features have some code in common files ie. One PHP file have the code for one feature as well as one other feature.
But client will ask you to upload only 2 feature out of 10 or 15. Files are common if you upload that file directly will leads to error problems because they have code for other features. If you upload all updated files then all feature will be live.
A possible way is go back and comment out that feature which is not needed live for now from common files. But there is possiblities to forgot to comment anywhere else.
This is also not a good way and at last client will say what happen everything was tested on development server and why these bugs and errors are introduced on live server.
This will reduce the faith on developers.
I faced this problem many times and could not found any good way to avoid these issues. So I am thinking that you guys also facing or faced this problem.
I am thinking versioning system can help here.
How you guys are handling this?
Could you share ideas?
The situation you are describing is impossible to manage sanely. I don't believe it would be possible to make this situation work, but the real question is why would you want to?
There are a number of issues with the scenario you describe, but the core issue is really this. You are testing one thing, and deploying another. You acknowledge in your question the interconnected nature of changes. In reality it is even more difficult than you describe. You simply cannot know how a system will behave when you try and deploy parts of a tested solution. Why test it at all?
The only sensible solution I can see is to have a sandbox environment where new features are demonstrated. However keep your test enviornment only for testing stuff that will go live. So in your example the one or two features are in test, ready to be signed off for prod, and the other featues are locked in the sandbox.
This leads to the next problem, which is managing your source code. I don't see any sane strategy for managing the arbirtrary inclusion of features from a code base. Even under the mostflexible system I know, Perforce, any branching straegy would require awful resolves on merges as you try to move stuff in and out.
I have seen this happen, and believe me it gets very ugly.
I suggest you come up with a better solution. Talk to your client and change the way things are done. It will be better for you, and in the long run better for them.
A solution could be to use cheap version branching as provided by VCS such as Git or Mercurial. The project would consist in many feature branches used to develop said features and build branches where feature branches would be merged and adhoc fixing would take place. When a build branch is ready for test, it is tested, fixed if needed and then the build branch is shipped to production platform.
When features have been validated, the build branch can be merged into remaining feature branches so the branches under development can integrate the "official" changes.
To sum up, the application is custom built from existing feature branches as needed.
One reasonably sane way to manage this on the code level is to isolate each feature into a plugin. Then you can add/remove features on-demand by simply enabling or disabling corresponding plugins.
But this solution has certain costs:
Time to develop and test plugin engine for your app
You need to test every plugin configuration (set of enabled plugins and their versions) that is going to be deployed. Otherwise there's a risk that this specific set is not compatible and end users would be first to see resulting crash, or data loss, or some other horror
Additional time to wirte plugins the way that they're minimally dependent on each other.
It's usually worth it only if you have many clients with different needs. In your case, I'd recommend explaining cost of separately enabling features to your client to see if they really need it this hard. Most likely, they don't
I am deciding on a framework to try out for PHP. I have narrowed it down to CakePHP and CodeIgniter. I have a couple of questions for any of you who have used or are familiar with both:
I like the fact that CakePHP keeps most of the code outside of the webroot by default. Especially since I may end up using a single framework install for multiple apps. I see CodeIgniter will do that too, but you have to configure it and move some stuff around. Is that workaround secure and reliable, or is it an afterthought hack?
Which (if not both) is easier to upgrade, and maintain over the long term? As new versions of the framework (and PHP itself) come out. I don't want to find my stuff either breaking, or becoming outdated.
Edit:
This is a very old post, but I thought I would update it with what I finally ended up doing, which was to use Kohana.
You should try both frameworks for a week or so, building something trivial (like a blog or wiki) in both, and see which you prefer using. Whatever makes the most sense to you will probably sustain you the longest through upgrades an deprecations.
CakePHP is in a bit of a volatile state right now, still unearthing bugs while pushing to release version 1.2 (which is not backward compatible). I wouldn't suggest building a critical application with it if you need something rock solid right now. If you can wait a month or two for things to settle, then it's probably a moot point.
To address your concerns:
1) Cake and CI do it the same way (iirc). They are equally secure, reliable, and hackish on this front.
2) Everything changes. If you need concrete, perpetual assurance of stability and backward compatibility, roll your own framework. There's not that much to it, and you're guaranteed that nothing changes unless you want it to.
I have deployed multiple applications on CakePHP and it's been a very, very, nice experience. You can't go wrong either way, as both are solid.
is a non-issue.
CodeIgniter has a sponsor behind it, so it's definately the one to choose for the long term. Also, it's faster.
This is a non issue. The app has a couple of lines which says where the core and your application code lies. You just need to change those lines.
You can never anticipate this one.
The state of PHP is a wildcard here. One app (CI) is built to be compatible with PHP4 the other requires PHP5. If you need to deal with the possibilty of a web host only supporting older versions of PHP then you need to go with CO.
Another issue is unit testing. If you require your framework to ship with tests, then CI is not the way to go.
Personally, I feel comfortable with CI because of the corporate backing. The company behind CI is making real profit from their efforts. Though CI is free, their paid product (ExpressionEngine) will eventually live on CI. The same could be said of the Zend Framework and even the birth of Rails (originally built for Basecamp.)
A minor correction to an above comment: both are compatible with PHP4, not just CI. Also, I don't think that having a sponsor makes CI and more or less upgradable or maintainable. Money doesn't solve those problems in the least.
I use CakePHP for a variety of applications and I've been happy with it thus far. 1.2 is a huge improvement over 1.1, and while the library source may change from RC3 to Final, I don't think any code you write will become obsolete. My only niggle is that the Manual isn't as comprehensive as it should be (in my opinion), and I end up in the API quite a bit. The trade-off there is that I now understand the code behind the scenes very well. In any case, I highly recommend it.
On the other hand, I've never played around with CI, so I can't recommend CakePHP over CI. I would take each for a spin and see which one grabs you. Whichever one you choose, study the hell out of its conventions and capabilities. When I started with Cake, I unwittingly wrote a bunch of code to do something Cake did "automagically" by having me set one variable in the controller.
CodeIgniter is very flexible as you would see once you try it. So how your application would be maintainable would fall you your hands.
I have also deployed multiple applications using the same installation. I usually create 2 applications for CMS projects (one for admin, one for the front-end).
To address both of your questions from a CodeIgniter perspective (I don't use Cake):
1) CodeIgniter doesn't keep itself outside the webroot by default, but it can do so with some very simple changes. The first part of my CI tutorial series explains how to do so, along with a walk through of the setup of a new CI instance. Once finished the only part of CI that needs to be in the webroot is a small index.php bootstrap file.
2) I've got an application which I originally developed in CI 1.4.x and I've sucessfully migrated to 1.5.x then 1.6.x. With each new release the CI dev's make available detailed upgrade instructions laying out what needs to be replaced so upgrades are fairly easy.
Jim.