Let's talk about continuous delivery

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 …

[1Rafayal]

I felt compelled to post a response to this.

From going by the article, it suggests that Git is the cure all for problems with version control.

Personally, I think version control lives in your build server, like Jenkins for instance, or in your artifact repository, like Artifactory etc.

Developers working with Git wont normally be concerned about the version number, they are just concerned about the branch they are working from. DevOps or build & release or whatever you want to call them, they are the ones concerned about versioning.

Additionally, you should never rely on a version number during a deployment - this information should only be used as a guide to what has been deployed. For confidence in your deployment you should also be verifying checksums and if you feel so inclined, comparing the binaries between the source of the deployment with the deployed artifacts at your destination.

To go further, if you are working with a web application, you need to verify that the site is up and running etc - something you cannot do with a version number.

Whilst Git does allow a great deal of flexibility and, imho, it is easier to use than SVN, it is only part of the tool chain.

[TkH11]

Version numbers are entirely valid and very useful, and if they are used, they should be relied upon. I don't accept the premise they should be used as a guide. If you define a configuration and the configuration items within that configuration are specified by version numbers, then you should be able to rely upon them. It's black and white, if the version numbers are provided for that configuration item, then it must be the correct number for it.

I work on systems where both high level source code is deployed to the production environment (it's interpreted and that's just the way the application works) and where binary files are deployed.

For those text based high level language source code files and text based configuration files, it's appropriate to use a version number in the file, either handwritten in with a comment header block detailing the change history, or automatically inserted by a configuration management tool.

For the binary files, that's not possible, and hence, checksums are the way to be sure of what version the file is at.

So both textual version numbers and checksums are complementary, and release notes which then state the version numbers of the modules in the build can reference both.

[Adam Connelly]

Nice Perforce Advert

I managed to read at least 30% of it before my eyes melted with all the buzzwords.

[1Rafayal]

Re: Nice Perforce Advert

agreed, this is just another poorly written piece on DevOps.

[amanfromMars 1]

Re: Nice Perforce Advert on a No Joking Matter:-)

I managed to read at least 30% of it before my eyes melted with all the buzzwords ….. Adam Connelly Posted Wednesday 11th September 2013 12:30 GMT

That is as may be, AC, but it all made a lot of perfect common sense which can lead anything and everything quite sublimely/effortlessly/stealthily in a right direction ...... [with any tendency or wayward coding which would result in a wrong direction always producing conflicts and difficulties which stop seamless DevOps progress].

And much the very same thing was said earlier in another version of a parallel mirroring program dealing with similar processing albeit in another field/interest/domain/Live Operating Virtual Environment ........ http://forums.theregister.co.uk/forum/1/2013/09/10/boffins_propose_more_spookproof_crypto/#c_1953748 ........ and which you might like to note and register is also fully operational too and DOing its AI@ITsWork Quantum Communications thing …. and even already floating its wares into and onto admittedly highly specialised markets with rabid rapid money makers targeted for feeds of seeds and needs/core future source.

I Kid U Not.

[vagabondo]

Much ado about not very much.

"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"

Isn't that called bug-fixing?

And the rest of this article seems to be about PHB style project management and the aforementioned buzzword blitz.

[TkH11]

Re: Much ado about not very much.

Yes, agreed. I think the description of what continuous delivery and the analogy of a car was quite poor.

I'm not a CD expert, but it seems to rely heavily on automation (and so it should, it takes out the human and reduces the error rate), but it seems to me that the emphasis is on, as you noticed, bug fixing!

But then the question is, so who's doing, when are the new features being integrated into the build?

I have worked for 15 years in development and for 5 years in operations, and both need to take place, bug fixing and new feature introduction. Generally I've seen project managers focus on putting in the new features and completely ignore the defects that have been identified during the operational life of the software.

[annodomini2]

Re: Much ado about not very much.

And in the non-fantasy land of advertising, there is such a thing as customers who tend to dictate what they want, irrelevant of your process.

[Anonymous Coward]

Managing the management tools

So, in other words, we need a management tool to manage the management tools.

[Robert Forsyth]

What happened to Continuous Iintegration?

That is all.