In an earlier article I talked about what Continuous Deployment was and how it fits into the modern programming process. We took a small swipe at how it works, but some people (okay, one person) felt that I could have gone into more detail and they were right. So, here’s a more detailed description of how Continuous Deployment works in the trenches and how it can change your life.
The essence of Continuous Deployment is that you use automated tools to do a lot of the heavy lifting. This means there may or may not be a bit of a learning curve when you first get started. A number of software elements are brought into play, and if you already know how to use those, great. If you don’t, just remember that this is a learning curve, not a barrier.
Version Control
The first thing you want to do is establish a baseline system, generally through the use of version control. With the Continuous Deployment process generating new releases of the software every day or so, having a common updated version that people can test against is crucial. You could keep track of your code revisions yourself, just as you could build your own automobile, but most people opt for a version (or revision) control system. Everyone has their particular favorite, although it seems Git is the most popular right now.
I won’t get into Git here, but there are close to a dozen articles already on SitePoint such as Mark Cippola’s Git: A Designers Primer and Sean Hudgston’s opus Introduction to Git. Oh, I almost forgot Jess Genevieve Brown’s Getting Started with Git. I like to highlight authors who use their middle name. I always wonder what would have happened if Willa Cather hadn’t dropped her middle name, Yvette, just before publishing O Pioneers!.
Naturally, you will also need an environment, a clone of the production system, in which the application can be run and tested. Most of us probably already have a solid test system, but if you don’t then you need one.
The bottom line is: get a version control system and find a way to define a baseline system. This will change with every Continuous Deployment update, but you need one system that everyone can agree is the gold standard.
Commit to Automated Testing
The next thing you need is the ability to do some major league testing. The essence of Continuous Deployment is to have updates to your code occur all the time, not just at the end of a quarter. But another aspect is to produce not just code, but good code, essentially bug free code. And to do that, you need to test.
I’m not talking about testing like how the boys and me used to do it, banging through the application doing whatever we could think of and hoping it would be enough (and, of course, it never was). No, I’m talking about some real fine testing, automatic tests that put your code through its paces.
PHPUnit contains a large number of standard tests (assertions) that can be performed on your code. If there are problems, an exception message is generated and you are made aware of the problem.
Assertions are checks that you will actually build into your software. In the very excellent documentation that PHPUnit has, it talks about how you can check the validity of the code by simply printing out the values the code produces, but that is a very manual and primitive way to test the code. From there you can move to a situation where you write your code so that the code itself determines if there is a problem or not and prints out an appropriate message. This doesn’t require you to look at values and is more automated. The final step is to increase the sophistication of the test and only produce a message only if there is a problem.
There are also a number of articles on SitePoint related to PHPUnit, starting with Michelle Sanver’s Getting Started with PHPUnit. Others include Error Condition Testing with PHPUnit by Matt Turland, and Introduction to Unit Testing in PHP with PHPUnit and Be More Assertive: Getting to Know PHPUnit Assertions by Chris Cornutt. There are also a number of articles related to how PHPUnit does or does not interface with a variety of frameworks and other software.
Build Software
And finally, you need a piece of software generally referred to as “build software” that automates the process of putting the new code in with the existing code, running through the test scripts, notifying you of any problems, and then, if all goes well, pushing the new code into your production and test environments. Examples of this include Cruise Control, Jenkins, BuildBot, Bamboo, etc.
Jenkins is very popular with many developers and there are several articles at SitePoint related to it, starting with J. Armando Jeronymo’s two part series Continuous Integration with Jenkin. This is also a very good article on the general topic of continuous stuff.
No matter what you use, the operative word here is ‘automatic’. There is no advantage to updating your site every night if it takes the efforts of five people over a two day time frame to move the new version out there. Speed is important but so is a lack of human involvement. Simple is good, automatic is better.
Conclusion
Continuous Deployment / Delivery / Integration is not for the faint-hearted. It is demanding and has a lot of rules and requirements and they must be followed, or can you spell D-I-S-A-S-T-E-R? But for teams with a number of developers, particularly remote developers, and the business need to update the code on a very rapid and ongoing basis, it can be the only game in town.
David ShireyDave Shirey is owner of Shirey Consulting Services which provides business and technical project management, EDI set up and support, and various technical services for the mainframe, midrange, and desktop worlds. In addition to PHP Master, he also writes frequently for MC Press and Pro Developer (formerly System iNews). In his free time, he tends to worry vaguely about the future and wonder obsessively how different his life might have been if he had just finished working on that first novel when he got out of college.
