The Reg’s group editor Joe Fay will be your host for the conversation.

You can register before the Live Chat for free, and receive an email reminder before we go live.

Continuous delivery has emerged as way of avoiding some of the traditional gates and bottlenecks in development. The theory goes that you can emulate the internet/mobile app spirit by defining and managing delivery as a single joined-up iterative process spanning the whole of the lifecycle from requirements gathering, through design, build and test, to release into the live environment.

But continuous delivery is still more talked about than practised. People have talked about joining up development and operations for over a decade, but the two camps still largely work independently in most organisations. It’s also still the norm that delivery of new capability or updates revolves around ‘chunky’ releases that are built and tested, then ‘thrown over the wall’ for deployment.

Meanwhile, one of the most frequent complaints we hear from senior business guys about IT is that it always takes too long to get stuff done. But while IT usually gets the blame for delays in implementing "change", it is often the case that business "change management" processes slow things down.

With this in mind we are focusing this Live Chat around some key questions:

Are people seeing the demand for more rapid/ongoing rollout of new and enhanced capability?

If so, which parts of the business and which types of application account for the demand?

Are there any parts of the business where the traditional ‘chunky release’ approach to delivery is still a hard requirement, and why?

What do ops guys need to ‘get’ about development, and vice versa, as a pre-requisite for bridging the gap between the two camps?

What needs to be thought through in terms of where and how different types of testing take place?

What, in practical terms, does it take to smooth out the lifecycle and create a continuum from a process perspective? Are there lessons to be learned from experiences with agile development?

What, specifically, is the role of tooling in this new joined up world? Is new capability required or is it just a case of integrating the silos of management? Is it possible without a common version management platform?

Are there hidden dependencies in continuous delivery? Aren’t releases more than compiled source code? What about documentation, test plans, budgets etc? Or are these very advanced topics and perhaps no one has reached that level of maturity yet?

What are the most common problems people are likely to encounter when they start driving down this route?

What can you do to stack the odds in your favour – e.g. tips, tricks and traps to be aware of? Are business units ready to change how they work to exploit new opportunities IT may make available? How quickly and how frequently can business processes and people really alter?

“Automate everything” is a common mantra for continuous delivery. Is that possible? What processes should or must be manual? Why? What can be done to mitigate risk?

A bit more disruptive – is Continuous Delivery a mistake? Why keep pushing releases into production? Is there a risk of too much too fast for customers? Shouldn’t customers/users be in charge?

You can join the conversation below, and remember, registering will ensure you're reminded on the day. ®