Continuous Delivery

Why we need to utilise continuous delivery to improve our cloud offering

Everyone in any job, any role, or any sector will be familiar with the phrase “as quickly as possible” – tasks need to be completed, reports filed, and deliverables delivered. That’s just work; it’s the expected punctuation to any given instruction. However, if you are a software vendor or work in IT, often “as quickly as possible” can be a little bit more open-ended than it sounds: tasks may be completed, updates prepared, deliverables readied, only to sit on a shelf until there are enough updates to constitute a ‘major’ release. As quickly as possible soon becomes as long as it takes. Problems go unaddressed for months on end and by the time the consumers or end users get a chance to provide any feedback, their patience has worn thin.

As quickly as possible is also when the end user wants new features, bug fixes, or increased functionality. So why would vendors and organisations insist on rigid development and release schedules with maybe only one update a year? In the world of IT, it is hardly surprising that such projects are seen as a constraint on the modern, dynamic business. Something must change.

Luckily, there is a different model. One that has already seen marked success in fast-moving, rapidly evolving areas such as SaaS: Continuous Delivery. Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.  It aims at building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

Continuous delivery changes the economies of software development, and provides more rapid business idea validation, reduced defect rates and improved service restoration times when a failure does occur. The primary purpose of software delivery is to provide a product to the customer that will validate a business idea, and ultimately provide value to the end-user. There must be feedback between the customer and the business, and this iterative process must be performed quickly, cheaply and reliably.

This feedback from the consumer is integral: what do they have to say? What do they like? What major issues are they reporting? This approach requires an understanding from your customer base as well as those within your organisation: not everything will be perfect straight away, but through open dialogue and consistent working and tweaking, things will quickly improve and change for the better. This methodology also ensures that certain issues will become necessarily prioritised. It also means than organisations will be quicker to respond to new demands.

At GMS, it’s clear that we need to implement this same methodology in order to grow and adapt to the current market’s demands. And we will. Our desire to change everything about our development cycle, and in the process, completely turn perceptions on their head.

I had an informal interview with one of our development managers – Jonathan Joseph, to get an idea of continuous development in (our) real world:

TP: How have you seen development methodologies evolve with your team?

JJ: We came from pretty much a traditional waterfall dev model – using established project management structures – you know – Gantts, MS Project. It was ok, but I really felt the road block was with a granular view of project requirements, and with sense of periodic achievement and delivery.

TP: What did you do to change your processes?

JJ: In my view there were two primary issues to address – swifter project (and sub-project delivery) and communications. I wanted everyone to talk more, collaborate more efficiently and deliver working code at a higher frequency.

However, what we actually did (and it sounds a bit glib) was wholly engaged with the agile methodology. We deployed dedicated development and project management software, we re-skilled and re-tooled internally, and we shifted from a shuttered and siloed team culture to one that that promoted and rewarded team work and intellectual sharing.

TP: What was the practical results of these changes?

JJ: Quite a lot of primary benefits actually, I’ll try to précis with what we ended up with:

• A more engaged user and product story planning team – we understood what was going to be built and what the client wanted!
• Cleary defined bodies of work with clear milestones and delivery dates.
• Visibility of the dev process, both macro and micro.
• A higher frequency of delivered, working product.
• Happier stakeholders across the whole team.