Continuous Integration for Front End Developers
Most software developers, especially those with a grounding in Agile development methodologies, will probably be familiar with Continuous Integration
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
The emphasis above is mine, purely as it’s at the heart of what I’m going to ramble on about. A little closer to home Ryan King just posted about a new site; inursite. The premise is simple; enter a few of your sites and inursite will visit them once a day and run a markup validation service over the page. You then get a feed of the pass or failure status. It’s simple but brilliant. For example, I have this very site added to the service. If I put some invalid markup in this post, tomorrow morning I’ll get an item in my feedreader telling me of my mistake. I’ll get that every day until I fix the problem.
This green/red (pass/fail) type approach to simple tests is what I find most powerful about continuous integration systems like “Cruise Control:. Ryan asked over on his site in one of the comments what I’d like to see, so lets see:
- Has all the CSS been compressed using something like CSSTidy.
- Has all the javascript been compressed using something like JSMin.
- Does any Javascript pass the harsh taskmaster that is JSLint.
- If my markup a little bloated? Maybe I could set a maximum size for the markup and get a fail is I go over that.
- Ditto CSS file size.
- Ditt Javascript.
- Ditto images.
- If pages have associated feeds, then validate them as well according to the relevant specification (probably RSS or Atom).
- How many HTTP Requests does it take to load the whole page, including all the relevant assets. I’d like to be able to set a maximum number.
- How many hosts are required to load the whole page? I’d like to be able to set a maximum number and get a fail if I go over that.
- Is the page gzipped on the server.
- And just to keep this topical, does the page have either the IE8 meta element or the associated HTTP header set to a particular value.
Lots of this is front-end best practice, some coming from the YAHOO! exceptional performance work. It’s something I’ve touched on before too. Can anyone else think of other things you’d like to see when you’re working away crafting markup and CSS? Once you have all these tests running you could display them in widgets, gadgets, twitter, firefox extensions, large displays, mobile devices, the works.
Now that sounds like an awful lot of stuff for one person (or even for one application) but I have something else in mind. If inursite allowed you to hook up external webservices which accept a URL as an argument, along with any service specific parameters, and return true or false then, in theory, anyone could add their own custom checks to it. This becomes particularly useful for larger teams than are likely to have internal quality tools already. On top of all that I’d probably pay for a service like this that let me run it on demand (rather than once per day) – or maybe even better, pay for a downloadable version (a.l.a. Mint) I can install locally.
As you can probably tell, I think the general idea of continuous integration for front end web developer is one for which time has come. It’s simply part of our discipline growing up and becoming more professional. Whether Ryan looks to extend his fantastic simple service in this direction or not I hope something will come along that does all this and more. I might even work on it myself – but then I always say that!
Comments
That level of automation would be a god send. I recently found I’d broken a site’s XHTML through some typos (doh), and the rendering in IE6/7 because conditional stylesheets weren’t being loaded. If these were being checked automagically, they wouldn’t have happened.
One potential addition to the list: how about automated screenshots of the homepage being sent through from a range of browsers?
Neil - 5th February 2008
Hi Gareth,
What about using Selenium as well, to assert that certain pieces of content or markup are present?
www.openqa.org
Tim Beadle - 5th February 2008
@Neil My sentiment exactly. Screenshots would be cool too. Something like Litmus (or even using it as the external service)
@Tim Good idea, though I’ve never really got on with Selenium. The Lime Testing Framework from symfony also has a markup assertion testing suite, using CSS rules to specify the existence of markup.
gareth - 5th February 2008
@Gareth: Lime Testing Framework presumably only applies if you’re working in PHP. We’re a Java/JSP house, so either a Java solution or something entirely independent of the backend, like Selenium, is required.
Tim Beadle - 5th February 2008
@Tim yeah, I just like how the CSS assertions work. But if you set everything up in a service orientated manner you could have remote services written in anything. I agree it should be language agnostic (which is why a web app makes sense) as front end devs work everywhere.
gareth - 5th February 2008
@Gareth: we don’t even have PHP installed on our Linux servers :(
Tim Beadle - 5th February 2008
I think a lot of what you proposed can be taken care of without the automation; surely you should be taking care of a lot of it anyway as you develop?
Having said that, if it could detect a WordPress site and make sure the author has fixed the tabindex fault on the comment form it’d be a godsend! :P
Steve Woods - 5th February 2008
[...] Gareth Rushgrove has posted on continous integration for the front end. [...]
Javascript News > Blog Archive > Continous Integration for the Front End - 5th February 2008
@Steve Absolutely. But the beauty of automation is, once set up, it doesn’t cost time every. single. time. you do something. Validating my HTML is boring and time consuming, especially as I make relatively few mistakes (I like to think). It’s too easy not to run a good test suite unless you automate it. If something tells me I got something wrong then I’ll fix it.
Now put all that in the context of a team of people working on a few decent sized projects. How does the lead or project manager or whatever ensure quality? You have to trust people to some extent but I’d still much rather automate away a load of boring repetitive work and then concentrate on real problem areas.
gareth - 5th February 2008
Thanks for all the feedback. You have some really good ideas there that I’d like to implement. Its just a matter of time and priorities at this point. I’ll likely add CSS validation, feed validation, link checking and crawling first. Hopefully within the next couple of weeks to a month.
And there’s also likely be a subscription service soon, which will be differentiated from the free version based on how many URLs you can enter and whether it will crawl or not. Not promising anything, though. :)
Ryan King - 5th February 2008
[...] Itt pedig kicsit bővebben a folyamatos integráció módszeréről, ami a Ruby / Rails / Merb világban is eléggé elterjedt. [...]
Egyszerű red/green frontend ellenőrzés : Pixelszabászat - 6th February 2008
G, thats a really interesting article!
Rob - 18th February 2008
High Performance Web Sites: Essential Knowledge for Front-End Engineers
Great Book about performance tips.
araba - 19th May 2008
Comments are now closed.