Continuous Deployment of iOS Apps with Jenkins and TestFlight

I thought it was about time I should put together a simple guide on using Jenkins to build your iOS application – and for those of us that use the awesome testflightapp.com website for managing our iOS app distribution for testing, I have included details on creating a Jenkins job to publish the latest successful artifact to testflightapp.com.

But I want to make an omelette … !

Some people love it, others hate it – many people just don’t get it. So what is Test Driven Development ?

Wikipedia has a page on it, there are heaps of blogs talking about it and our own Ben Teese has put together a great presentation on how to get started.

.

He didn’t invent the phrase “TDD is specification by example”, but it sums things up well.

Iterations, increments or Sprints ?

So what’s in a name … ? Does it matter what you call your chunks of work ?

In many ways it doesn’t – different people use the terms inter-changeably. Sprint is specifically a Scrum term, XP tends to use Iteration, each different Agile approach has different ways of defining and using the terms. However the common ground is that they are regular, repeated timeboxes used to manage the work to be done so that there are regular checkpoints and feedback as part of the project process.

However there are some important differences between the processes of iterating versus incrementing.

Jeff Paton has posted a nice summary of the difference, along with some pictures that help to make it clear:

Iterating: Starting with an idea of what is wanted and refining that idea to get the desired result

Iterating (thanks to Jeff Paton)

Incrementing: Starting with a much more definite understanding and building piece by piece

Incrementing (thanks to Jeff Paton)

Both still have the benefit of regular feedback and both can still deliver usable software at the end of the timebox. Incrementing is probably more useful when requirements are more stable or better understood, whilst iterating allows a more agile response to changing or unclear requirements. There’s no reason why a project can’t use both, at different times and for different features – in fact most projects probably should.

So – whatever you call your timebox periods, make sure you understand whether you want to iterate or increment.

Beauty and the Beast…

One of the challenges working in a consultancy on client site, is adapting modern ideas and techniques onto existing legacy systems. The temptation can be to sweep away the old and replace with the new, but most times this is not possible (or even desirable as it introduces a whole new element of risk and cost). In the following article, I detail our successful attempt to bring “continuous integration” via Cruise Control into an existing Cobol system. Article :
Cruise Control & Cobol

The Nokia Test – Are you doing Scrum ?

If you think you are doing Scrum, how do you know ?

There are lots of good books around, but – whilst Scrum is deliberately quite simple – it can sometimes be easy to lose sight of the principles. Over on the Agile and Business blog Joe Little has posted the test used by Nokia to determine whether a team is using Scrum or not.

I’m happy to say that some of the recent work I have been involved in does quite well on the test, other work not so much …

Agile Development with CMMI … ?

One of the common criticisms levelled at Agile development – particularly by those who haven’t experience it for themselves – is that it is little better than hacking. In particular, that the reduced focus on documentation is evidence that the processes aren’t managed or controlled.

So, for a corporation that has invested significant time and money in process improvement and has reached CMMI level 3 or above surely Agile development is not an option ?

Not according to Mark Paulk who looked at Extreme Programming in the context of CMM(I):

“XP has disciplined processes, and the XP process itself is clearly well defined. We can thus consider CMM and XP complementary.”

So who is Mark Paulk ? He worked at the Software Engineering Institute as leader of development of the CMM for software.

Eclipse Web Tools Platform: Bringing Joy Into The Lives Of Others…

Well, this week I’ve been able to introduce another developer to the Eclipse Web Tools Platform project and it’s been satisfying to see the look of joy on his face as he discover its hidden gems. As well as the standard stuff like HTML syntax highlighting, error highlighting and formatting, there’s also the more powerful stuff like completion on any tag library you want. Sure you can get this sort of thing with MyEclipse, but the WTP is free.

The only catch with this project is that it’s a big one with a couple of dependencies – which makes it much, much easier to install if you just use the Eclipse Update Manager and get it to automatically load dependent frameworks. I’m surprised at the number of developers who still install Eclipse plugins and features using the old-school technique of downloading a zip file and unpacking it into their plugins folder. You can often even upgrade all of Eclipse using the Update Manager!

However, we haven’t been able to use the Update Manager this week as we’ve been working behind a corporate firewall that blocks it for some reason – even after we configure the HTTP proxy access. Initially we resorted to the old-school approach (with all of its consequent difficulties) but then remembered that you can get distributions of Eclipse that are prepackaged with WTP. After that there was no looking back.

Fixed Price or Agile ?

Mark raised some very good points in his comment against my recent post on welcoming change in projects:

“One main barrier to these approaches being adopted in the past was the engagement/contract models that our clients dictated. If the project needs a fixed cost, you usually need a fixed set of requirements.”

So what to do ? Does this mean that an Agile approach can’t be used ?

Much of what makes up Agile development is simply sound development practices, but what specifically could we take from the Agile philosophy for use in a fixed price contract ?

Let’s look at a typical situation we encounter – responding to an RFP or other tender. The client has provided some overview of the goals, objectives and requirements, a target completion date and wants a fixed price quote.

1) Respond to the RFP in the best way that you can
You need to make (and document) assumptions, try and fill in the gaps, use your experience – anything you can do to improve your information. And you need to estimate the work. There are no silver bullets here, with Agile or anything else, you just have to do the best that you can. However, if you’re used to working Agile you’ll be used to identifying requirements and putting together good estimates fairly quickly – treat is just like a normal planning session (someone will have to pretend to be the customer !).

2) Plan to deliver business benefit early
This is core to an Agile approach in any case – “early and continuous delivery of valuable software” – but it also means that if something surfaces during the project that significantly affects your original estimates you’re in a better bargaining position. A client is much less likely to be concerned about a suggestion to drop some of the minor functionality if they can see a working solution that already implements their most important requirements.

3) Promote your Agile approach as a benefit as part of the proposal (and put your money where your mouth is)
The use of Agile processes is now widespread, almost mainstream, so is something that can add value to your proposal. Even if your client isn’t really aware of what Agile processes are all about tell them what you are offering – choice. The ability for them – the client – to have control over the process and end it at the end of the next iteration if they’re not happy. Or maybe even if they are – because they might by that stage have what they need to achieve the business benefits they are after.

4) Do the job better
In the worst case – even if the client is not interested in Agile processes or iterative development – you can still benefit from those processes as an external vendor / supplier. If your development processes are more efficient and more effective then you are going to be more competitive at proposal time, as well as more likely to deliver on time, on budget and to meet (or exceed) your client’s expectations.

As Mark also points out in his comment – things work better when you have “trusted partnering relationships where both parties are working for mutual benefit”. Or – as the Agile Manifesto puts it -“Customer collaboration over contract negotiation”.

The more you can demonstrate delivery of business value, the more you can develop trust. On the other hand, if you need to rely on the wording of a contract to protect your position then the project is already in trouble.