Feeds

Let's talk about continuous delivery

Skilful driver required: avoid bumps in the road

SANS - Survey on application security programs

Continuous delivery is defined as a process in which software development teams focus on deployment and refinement over and above any imperative to work on new features.

As a technical discipline this is fine in principle, especially if we know where we want to head with the project in hand.

But the navigation and drive for continuous delivery needs some sort of auto-GPS or steering mechanism to keep the wheels aligned.

If continuous delivery sees developers feed code into a versioning service, then we need a management tool to direct us from the start. Our steering mechanism and engine controls here come from a change and configuration management system, without which we may be expending energy for nothing.

Team spirit

Software application developers, and also the non-technical members of the team, need to be able to examine their workflow constantly. If that sounds a bit woolly, we mean that we need to be able to control which software changes are being mainlined into the production engine at any moment.

This control will allow us to merge changes into the production stream without the project coming off the rails. Think of it as a car driver wanting to perform a gear shift from second to third and not a block shift from second to fourth, or even worse a lunge from second to fifth gear that could result in a total loss of momentum.

It gets more complicated when we realise that there is more than one person at the wheel and they all need to be reading the same roadmap. Both the development and operations functions will need full disclosure of all project information and must be able to access it from a common system.

The importance of this will become clearer when we move past development and into user acceptance testing and full-blown production.

Intelligence quotient

It is really hard to do continuous delivery without a good configuration management system. This is because the programming team need to automate build, test and deploy tools and scripts multiple times. They also need to synchronise releases and know how to do a rollback if necessary.

These people are going to need expertise in multiple software tools, which requires a deep layer of intelligent code management to exist at some level or other.

Ok, in fairness, this is more of a task for the DevOps unit than for a pure developer unit, but the programmers may still have to create the documentation, processes or scripts to enable rollback and the like.

The challenge is being able to audit a system to show what was live at any point. We are also going to have to check and see whether our content management system can handle all the different asset types involved – not just source code, but also images, video, binaries, databases and so on.

So where do we turn? We have commercially branded version-control systems and repository tools and we have open-source alternatives.

With Git standing tall as a fully fledged versioning service of choice for many users, surely this is all the toolkit we need? Well, yes and no.

Git is strong but it does have weaknesses in areas such as Java code refactoring. It is granular and powerful on checksum testing but slower when working on various file types such as binary files, where we could argue that the team has less control.

But Git has remained very popular (it is one of Linus Torvald’s babies after all) and has had many advocates, despite its pockets of occasionally limited or partially challenged functionality.

Learn to love Git

This is why we have seen the bigger brand names in distributed version management align to dovetail with Git.

Perhaps some of these moves have been taken in part to uphold our suggestion that the heart of continuous delivery lies in configuration management. Let us dig deeper.

Late last year Perforce built Git Fusion to extend its enterprise version management capabilities to Git repositories. In this scenario, software developers currently using Git can continue to use their preferred Git capabilities but now also get hold of new tools for customisation, reuse and sharing of projects.

The technology proposition here is that Perforce users and Git users should be able to use the tools and methods of their choice, but still maintain a “single source of truth” and, crucially, a single interface for the central revision control system. This could be either Git or Perforce, depending on preferences.

Mark Warren, European marketing director at Perforce, says that if you want to have more than one version control system working together that's fine, but it is prudent to choose two that have had their DNA fused.

They should at least have aligned their roadmaps or partnered so that you can end up with one system of record – or more accurately even, one single system of (software code) record.

These are the essential building blocks for continuous delivery to exist upon a configuration management backbone. Going further, when Warren talks about configuration and version control of software code, he prefers the concept of “version everything”.

Under this umbrella notion (or versioning doctrine) we could be version controlling all the way back to the kernel source code. Better still, we could be version controlling (or versioning if you will) right back up at the modelling and application architecture level.

“The architecture of a modern application has code blocks, scripting, components and configuration information all the way through it. But there are also notes, annotations, compliancy documentation and perhaps even tutorials in video form making up the total application real estate,” says Warren.

“We almost need to redefine the constituent parts of an application and feed all of these elements into our revision control system if we want to stay on track.”

Mind the air gap

As software development teams now work to push out multiple variants of an application across different platforms, these control factors become even more important.

In an ideal world, continuous delivery starts to become ingrained into the core functions of the DevOps team so that it is symbiotically consumed by the automation and feedback functions that these guys live by.

So is an “automate everything” mantra a good idea when it comes to change and configuration management?

Yes mostly, but not absolutely always, according to Warren. “There might be a 10 per cent human factor in continuous delivery and change management in industry areas such as defence,” he says.

“This could be where an ‘air gap’ exists between developers and operations working together, for example a floppy disk is carried across the hall from one area to another to install sensitive data. Here it becomes more a case of automate almost everything.”

We shelve the change and introduce it at the appropriate point

The deployment process may also require peer review – an inherent part of this process. Tools exist in Perforce’s cadre so that developers can stop and request a review at any moment.

But when we say stop we do not mean that we need to stop the application running. We shelve the change, augmentation, bug fixes, new feature or introduction of a new piece of documentation and introduce it at the appropriate point.

Remember the hardware

These techniques work best for software and when there is a lot of automation and testing. Where hardware as well as software is being built, there is also a jump-off point at which you need to stop and make a prototype. Since prototypes are expensive, we want to be able to choose a point where we can perform this action effectively.

Have we convinced you yet that the heart of continuous delivery lie in configuration management, or change and configuration management to be more exact?

It has to be so because continuous delivery without revision control is like drinking from a fire hose, flying blind or anything else that entails a totally misdirected overload of power with no clear strategic end point.

Try continuous delivery without versioning control if you wish, but as a matter of good practice and good sense, we suggest that you don’t try and reinvent the wheel. ®

3 Big data security analytics techniques

More from The Register

next story
OpenBSD founder wants to bin buggy OpenSSL library, launches fork
One Heartbleed vuln was too many for Theo de Raadt
Got Windows 8.1 Update yet? Get ready for YET ANOTHER ONE – rumor
Leaker claims big release due this fall as Microsoft herds us into the CLOUD
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Ubuntu 14.04 LTS: Great changes, but sssh don't mention the...
Why HELLO Amazon! You weren't here last time
Patch iOS, OS X now: PDFs, JPEGs, URLs, web pages can pwn your kit
Plus: iThings and desktops at risk of NEW SSL attack flaw
Next Windows obsolescence panic is 450 days from … NOW!
The clock is ticking louder for Windows Server 2003 R2 users
Batten down the hatches, Ubuntu 14.04 LTS due in TWO DAYS
Admins dab straining server brows in advance of Trusty Tahr's long-term support landing
Red Hat to ship RHEL 7 release candidate with a taste of container tech
Grab 'near-final' version of next Enterprise Linux next week
Apple inaugurates free OS X beta program for world+dog
Prerelease software now open to anyone, not just developers – as long as you keep quiet
prev story

Whitepapers

Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Mainstay ROI - Does application security pay?
In this whitepaper learn how you and your enterprise might benefit from better software security.
Combat fraud and increase customer satisfaction
Based on their experience using HP ArcSight Enterprise Security Manager for IT security operations, Finansbank moved to HP ArcSight ESM for fraud management.