Continuous Integration with Flex – Introduction

• Tweet

• Tweet

The contract I am currently working on is for a large financial institution in Boston.
They want to explore new ways of working in our small business unit with the hope that some of our work may make it into the mainstream of the company.

We are not only experimenting with the projects we work on, but also trying out new (for the company at least) ways of working.

So, when my manager came to me late last year and started asking what we could look at next, there was a challenge that I and my workmates (Peter Hall, Ikezi Kamanu and Johannes Nel) had been looking to get our teeth into for a while — Continuous Integration with Flex.

So, here’s the trouble: I’m a lazy person, and I need to see tangible results for any effort I put into a task. Then I started looking into Continuous Integration, and finally I could see I would get a real and immediate benefit from unit testing. Have a look at Martin Fowler’s excellent article on CI for full details. This will tell you all the reasons from a technical standpoint why CI is a great idea. The one that stuck in my mind was the idea that whenever code is changed, a build is run, and if it passes tests placed against it, the project team gets to know about it. This isn’t just the developers, but the entire project team.

That for me is the real beauty of this setup, no more project managers, designers, business analysts or QA guys tapping me on the shoulder asking to see where we are. Because they are always kept up to date with where we’re at, there’s more visibility in the development process and less mysticism and panic.

So, having decided to try and get a CI process running , we set about getting this working with Flex. Most of the pieces are in place for this; the work we had to do was in joining the dots. I’ve put this together as a step by step process, although for many of them I’ll direct you to where someone else has explained it better than I ever could.