Expert PHP 5 Tools phần 10 ppt

Chapter 10 [ 399 ] Since PHP is an interpreted rather than a compiled language, we don't have the luxury of looking towards compilation to judge whether a project "built" successfully. That is why unit tests become so much more important during continuous integration. After all, checking a project out of Subversion into a local directory on the CI server tells us nothing about whether the application is actually working or not. Executing a suite of unit tests; however, will tell us a whole lot about how successfully the application is behaving. If you were slacking off on writing unit tests either before or after working on changes to your source code, you now have an added incentive. Not only is it good practice to write unit tests for the sake of your code, it is absolutely essential for setting up a CI environment. Think about it this way—if you are looking to benet from a CI process, chances are that there is more than one cook in the kitchen. In other words, the team working on your application probably consists of at least several developers, analysts, testers, and so on. Even if your code in itself is awless, think about all those times when others manage to break your code. No matter how loosely coupled your code is, there are dependencies that can cause your unit tests to fail even if another developer is making changes to his code. Having unit tests in place and executing them automatically during the periodic CI process will let all interested parties know if a test fails—especially the owner of the unit test and the developer whose code broke the test. So, if you are cherry picking chapters in this book and you haven't taken in the chapter on unit testing or don't know about it already, I urge you to do so now. Of course, if you are primarily interested in setting up a continuous integration process, while other team members have to worry about coding and writing unit tests, feel free to continue reading. Automation: Phing Integration has always been a necessary part of software development and testing. You can and often have to do this manually. But to effectively make the process continuous, we will look towards automation. It only makes sense to remove manual tasks as much as possible if our goal is to execute the integration process as frequently as possible. Download from Wow! eBook www.WoweBook.com Continuous Integration [ 400 ] You can think of the other tools mentioned previously, such as version control, unit testing, code coverage, as the building blocks of CI. Automation then provides the plumbing to make sure everything ts together and the information ows from one component to the next. I think this point is well illustrated in the following ow diagram: Star CI Cycle Discard previous build Checkout project Checkout Successful? Build project Build Successful? Execute Unit Tests Unit Tests Passed? Run Code Coverage Analysis Notify Observes Source Code Repository Generate Project Documentation Generate CI Reports Predefined Timeout Yes No Yes No No No Yes Yes Automation Continuous Integration Flow Observers Validate Coding Style Style Accepted? Download from Wow! eBook www.WoweBook.com Chapter 10 [ 401 ] You can pretty much use any automation tool you want. But, you should rst make sure that it is a good t with the rest of your suite of CI tools. You can even put together some PHP command line script to control this process, but there are other tools that we have encountered before that are a bit more suitable for the task at hand. If this were a book about Java, we would probably be working with Ant, but since we call ourselves PHP developers, we will be doing this with Phing. Besides, you have already mastered automating release and build related tasks in Phing after reading the chapter on deploying applications (haven't you?). So, it's time to put your new Phing scripting skills to use. Coding style: PHP_CodeSniffer Although the primary goal of the CI process is to make sure that the code base builds, executes, and passes the automated tests, it is also a great place to run project-wide tasks that also aim to improve the quality of the code and make it more maintainable in the long run. Validating the coding style you have dened for your project is one of those tasks. As we have seen in the corresponding chapter on coding style, PHP_CodeSniffer can be made to check all source les against a pre-dened coding standard. Any discrepancies will be reported and the developer who owns the le(s) or the one who last worked on it can be made responsible to bring the code into compliance as a matter of policy. The CI environment for our sample project will provide a PHP_CodeSniffer Report in the web-based UI; as well as, a graph to illustrate coding style violations versus compliance. Documentation: PhpDocumentor Generating and staging the project's code-level documentation is another non-essential task for a successful build. However, if developers are expected to create inline documentation, we should be consistent enough to generate and stage the documentation. Besides, this way the CI server becomes the perfect central place for locating the most up-to-date documentation. Download from Wow! eBook www.WoweBook.com Continuous Integration [ 402 ] Code coverage: Xdebug Even though we have devoted a whole chapter to debugging and the use of Xdebug, we didn't really touch upon the functionality Xdebug provides in terms of code cov- erage analysis. In relation to automated software testing, code coverage provides one or more metrics to measure how much of the code was actually exercised when running the test suite. You can state code coverage by focusing on different parts of software, including but not limited to the following: • Statement coverage measures how many executable lines (that is, ex- cluding whitespace or comment lines) were executed: "6,936 of 11,291 lines were executed." • Function coverage measures how many of your source code's functions were executed: "398 of 465 functions were called." • Decision coverage measures how many conditionals (if-then-else statements, switch statements, and so on.) have been evaluated to all possibilities: ."243 of 312 if statements have been evaluated to both TRUE and FALSE." • Path coverage measures how many of the possible paths of execution of the software actually occurred: " 4,939 of a possible 18,837 paths were executed." You get the idea. We basically want to know how much of the code in the project is actually being tested by our test cases. Complete code coverage (that is, 100%) is quite hard to achieve and requires extensive time spent on writing unit tests and verifying coverage. As a rule of thumb, code coverage of 80% to 90% is quite respectable. In our sample project, we will report code coverage by having a CI tool that is able to interpret the data output by Xdebug during unit test suite execution and generate the corresponding reports. Environment setup considerations In all chapters thus far, we have focused on a single tool to get the job done. Although I tried to select the most established and mature PHP-centric tools, at times it simply came down to preference or perspective. The case in this chapter is even more complicated than that. Download from Wow! eBook www.WoweBook.com Chapter 10 [ 403 ] Do I need a dedicated CI server? Continuous integration can be done on any machine, including a developer's workstation. If you can spare the resources in terms of memory, disk space, and CPU cycles, you can make the CI process the responsibility of an existing machine, perhaps a le server or even your version control system. Another factor in making this decision is the size of the team. If you are the primary observer of the CI output, it might be convenient to have the automated builds performed on your machine. However, if your team size were slightly larger, it would be important to have the CI server centrally accessible. Carrying it around on your laptop might benet yourself, but wouldonly serve to frustrate the rest of your team as they are trying to check the latest build output or consult the generated documentation. Do I need a CI tool? Continuous Integration is primarily a process and you don't necessarily need an application to follow it. For example, if your existing project has sufcient automation in the shape of Phing build scripts, you might be able to expand on the existing functionality and create a CI process without much fuss. After all, the tasks that need to be performed during the CI process are all ones that developers perform manually at one stage of the development process or another. In contrast, there are several reasons for adding yet another tool to the mix. A tool that provides the framework for automating CI builds. As you are deciding whether to add such a tool, you might want to consult the following list of questions: • Do I have multiple projects that need to be built and reported on? • Do I need textual and graphical reports on the CI process? • Do I already have a process that generates documentation from inline comments and makes it available to developers? If you decide that a specialized continuous integration tool is called for, you will learn how to install, congure, and run just such a tool later on in this chapter. CI tools Continuous Integration is still a fairly new phenomenon in PHP. Nevertheless, as PHP continues to make inroads into the development departments of large corporations worldwide and larger PHP teams are being assembled, I'm sure that CI will play an increasingly bigger role. Correspondingly, I expect more CI tools supporting or written in PHP to crop up. Simultaneously, the current offerings will most likely continue to mature. Download from Wow! eBook www.WoweBook.com Continuous Integration [ 404 ] CI tools typically provide us with a framework for implementing the whole process. These tools provide a unied interface to the variety of lower level tools that are operating behind the scenes. In addition, they typically provide additional functionality in the area of accumulating metrics, reporting, and notication. When the time came to decide which tool to use for setting up a CI environment and sample project, I had to choose between two serious contenders. XINC (Xinc Is Not CruiseControl) Yet another entry in the list of recursive acronyms used in software development, Xinc is a continuous integration server written in PHP 5 for PHP. As such, the focus has been on supporting PHP-centric tools, such as Phing. Xinc has built-in support for Subversion and PHPUnit. phpUnderControl The good news about phpUnderControl is that it was built on top of an established and proven CI platform. The bad news is that we will have to stray from our favorite programming language and use a Java tool instead. I am of course talking about Cruise Control, which is the tool underlying phpUnderControl. Continuous integration with phpUnderControl To properly illustrate continuous integration, we really need a project that meets the following requirements: • Unit tests have been created for all or most of the project • The source code resides in version control repository • Inline documentation has been written to conform to phpDocumentor syntax • There exists a well-dened coding style that can be validated using PHP_CodeSniffer Creating such a project from scratch is completely out of scope for this chapter, however, there are plenty of open source projects available that will serve perfectly as guinea pigs for our purposes. Since it has repeatedly come up in our discussion of coding style and frameworks, we are going to implement a continuous integration process for the Zend Framework because it satises all our requirements above. Besides, it will be nice to get some hard numbers on code coverage and unit test for a development framework that is aiming at wide adoption. Download from Wow! eBook www.WoweBook.com Chapter 10 [ 405 ] Installation phpUnderControl is built to modify an existing installation of CruiseControl and getting it installed is a three-step process. In particular, we have to: 1. Install CruiseControl. 2. Install phpUnderControl and its supporting les. 3. Run the command that tells phpUnderControl to modify the CruiseControl installation to allow us to properly display output for PHP-based projects. Installing CruiseControl CruiseControl is a continuous integration server written in Java. Since it was one of the earliest CI tools, it has reached a certain level of maturity. It is also being used by a lot of development teams, which is why it is a valuable tool with which to be familiar—even if you are not working in PHP or Java. Being a Java based application, you will have to have a working Java Runtime Environment (JRE) installed on the machine on which you are conguring the CI environment. Detailed instructions on how to install Java are beyond the scope of this chapter, but a good starting point will be Sun's Java download page: http://www.java.com/en/download/manual.jsp Assuming that Java has been installed, we can proceed by downloading a binary distribution of CruiseControl. If you are feeling adventurous, have experience with CruiseControl already, or know your way around Java source code, you can download one of their source code distributions or go directly to their Subversion repository. However, the binary distribution represents a quick and painless way of getting CruiseControl up and running. Here is the download page for CruiseControl. At the time of this writing, the most recent version is 2.8.2, but I urge you to download the most recent version: http://cruisecontrol.sourceforge.net/download.html Once the download nishes, simply extract the archive. Depending on your platform, simply execute the cruisecontrol.bat or cruisecontrol.sh script le in the application's home directory and barring any complications, CruiseControl should be up and running. Actually, hold that thought—before we are ready to start the server, we need to overlay CruiseControl with phpUnderControl and congure it to build our project. Download from Wow! eBook www.WoweBook.com Continuous Integration [ 406 ] Installing phpUnderControl The easiest way to install phpUnderControl is via the PEAR installer. phpUnderControl is being hosted at the PHPUnit repository. So, don't let the occurrence of PHPUnit in the following transcript confuse you—we are still only installing phpUnderControl. The important lines are highlighted in the above terminal session transcript. Basically, we have to do the following: • Let PEAR know that we are looking for beta packages, rather than the default stable ones: pear config-set preferred_state beta. We have to do this because we are installing version 0.4.7 of phpUnderControl, the latest as of this writing, which is nevertheless considered a beta release. • Inform PEAR of the existence of the components.ez.no and pear.phpunit. de channels:  ° pear channel-discover components.ez.no  ° pear channel-discover pear.phpunit.de • Tell the pear command line utility to install phpUnderControl from the PHPUnit repository along with all its dependencies: pear install alldeps phpunit/phpUnderControl. phpUnderControl relies extensively on the following tools, which will be installed with the alldeps switch if they are not present already. You should recognize these because I have devoted a chapter in this book to each of them: Download from Wow! eBook www.WoweBook.com Chapter 10 [ 407 ] ° phpDocumentor ° PHPUnit ° PHP_CodeSniffer If everything goes ok, you should see output similar to the above and phpUnderControl will be installed. Although we installed phpUnderControl using PEAR, you should visit the project's home page because it contains a lot of useful detail, only some of which we will be able to cover in this chapter. If the conguration of the project you are trying to build doesn't exactly match the one we are working through in this chapter, you should certainly start by looking at the documentation page: http://phpundercontrol.org Overlaying CruiseControl with phpUnderControl At this point, we have installed CruiseControl and phpUnderControl, but so far there is no connection between the two. We need to let phpUnderControl register itself with CruiseControl and allow it to make some modications, such as changing some of the output template and style sheet; as well as adding some images. The phpuc command line executable for phpUnderControl supports these commands: • install: Installs or upgrades CruiseControl with phpUnderControl • clean: Removes old builds and artifacts • example: Installs a small sample PHP project in CruiseControl • delete: Deletes a project and related les from CruiseControl • graph: Generates the metric graphs • merge-phpunit: Merges multiple PHPUnit output les into a single one • project: Creates a new PHP project within CruiseControl Unfortunately, not all these commands have been documented in the online manual. Fortunately, the phpuc command line utility includes help information for each of the commands. Simply type the following at the command line to get a description of the command and a listing of all the options. You will have to replace <command> with the actual name of the command for which you are trying to get help. DirkMacBook$ phpuc <command> help Download from Wow! eBook www.WoweBook.com Continuous Integration [ 408 ] The most important command of those seven is easily the install command, which we will be using to register phpUnderControl with CruiseControl. Please take a look at the following listing: We start out by making sure that the phpuc command line utility is indeed available and our shell conrms that it is located inside my machine's PHP bin directory at /usr/local/apache2/php/bin/phpuc. The install command requires only one argument, namely the path to the CruiseControl installation on which to operate. It then performs a series of le manipulations, some of which I replaced with "…" to keep the above listing short. That's it for the installation. If we wanted, we could start up CruiseControl, but there wouldn't be anything to report yet. We still need to go through the conguration to get it to build our project and display the metrics it collects during that process. Also, from this point on, I will be using CruiseControl and phpUnderControl interchangeably because the two have become fused. Although the underlying platform is still CruiseControl, the user interface identies itself as phpUnderControl. In a sense, both are working together to provide us with a rich continuous integration environment tailored for PHP. Download from Wow! eBook www.WoweBook.com [...]... for target php- documentor: cruisecontrol/projects/zend_framework/build.xml Here we are executing the phpdoc command... using PHPUnit > ... using PHPUnit > ... "svn-update ,php- documentor ,php- codesniffer,phpunit"/> codesniffer"> PHP_ CodeSniffer . in PHP 5 for PHP. As such, the focus has been on supporting PHP- centric tools, such as Phing. Xinc has built-in support for Subversion and PHPUnit. phpUnderControl The good news about phpUnderControl. pear.phpunit.de • Tell the pear command line utility to install phpUnderControl from the PHPUnit repository along with all its dependencies: pear install alldeps phpunit/phpUnderControl. phpUnderControl. www.WoweBook.com Chapter 10 [ 407 ] ° phpDocumentor ° PHPUnit ° PHP_ CodeSniffer If everything goes ok, you should see output similar to the above and phpUnderControl will be installed. Although we installed phpUnderControl