Continuous Delivery - Latest Comments

Re: How To Create A More Diverse Tech Conference

nobody — Wed, 30 Mar 2016 08:38:10 -0000

How dare people who make good choices have it better than those who don't!

Re: Why Software Development Methodologies Suck

Rosen Rosenov — Tue, 29 Mar 2016 18:13:34 -0000

I am sorry to say this, but adopting PSP/TSP is the worst thing you can do regarding developer productivity. I need to press a timer button every time I need to fart. PSP/TSP like a lot of other manager nonsense was developed to extract money from companies using vague claims.

Re: Visualizations of Continuous Delivery

Kamal Ahmed — Fri, 04 Mar 2016 19:58:12 -0000

Awesome ! can we get them in high density ? pls

Re: Continuous Delivery vs Continuous Deployment

vishal sahasrabuddhe — Fri, 14 Aug 2015 15:05:59 -0000

Nice one, CI and CD are not easy part of software development.

here is one more to read.

http://www.scmtechblog.net/...

Re: PCI-DSS and continuous deployment at Etsy

Paul Mooney — Thu, 18 Jun 2015 06:48:01 -0000

Very interesting, Michael. Do you segment your PCI-related software into separate services, or just separate software components? For example, if we consider payment-processing; do you encapsulate logic into source code modules contained within the PCI environment, and push code changes to production in parallel with your non-PCI environment, or do you encapsulate payment-processing logic into individual services in a SOA fashion?

In other words, does any given feature from your non-PCI codebase communicate with any given feature of your PCI codebase (accepting a credit card, for example) over a communications protocol such as HTTP, or do you simply provide PCI-related features as a packaged dll/jar, etc., that the non-PCI feature references?

Re: The 2014 State of DevOps Report is Here!

Jez Humble — Sat, 02 May 2015 23:01:32 -0000

Hi Brett

For various reasons we weren't able to publish the underlying data unfortunately. However I do have some resources that address the questions you have:

* I give a talk on adopting continuous delivery that addresses the problems you mention: http://www.infoq.com/presen...
* I wrote a post for O'Reilly just over a year ago with some more data: http://radar.oreilly.com/20...

* My new book, Lean Enterprise, expands on the information above.

Re: The 2014 State of DevOps Report is Here!

Brett Baggott — Wed, 25 Mar 2015 13:08:16 -0000

Jez, I don't mean this as criticism, I'm a HUGE fan of you and of continuous delivery, however, I was expecting this report to contain backing data, and I'm not seeing that. Don't get me wrong, there's great info and recommendations and I really appreciate all the work that went into it. I guess I was expecting more of a "here's what we recommend _and here's why_". The "here's why" part is what I wanted to see more of. I'm at a new company and I'm in the position of trying to "sell" continuous delivery. I've already sold continuous deployment in some areas, be we have certain areas where, "we just can't use all that continuous delivery stuff here", which means those are the _exact_ areas that would benefit most from continuous delivery (in my experience). I'm having a hard time finding resources that show "here's how you reshape from maintaining 15 release branches to sanity" and "here's why you want to". I was hoping to find some hard stats on the "here's why you want to" part in this report. Having said that, thank you so much for compiling this information, and for sharing it with us.

Re: On Antifragility in Systems and Organizational Architecture

Sven Malvik — Sun, 15 Mar 2015 15:54:51 -0000

A technical leader that doesn't care about old and stupid rules and guidlines and that has the energy to fight the fights was what it took to change our architecture from a monoliths into microservices. Sometimes it just needs one single person in a large organization that really cares to change.

Re: Visualizations of Continuous Delivery

Jullietta jung — Tue, 11 Nov 2014 05:53:41 -0000

Love this post. I was looking for some nice visualisation to demo QA's role in continuous delivery.

Re: Visualizations of Continuous Delivery

Bình Quan Duc — Sun, 06 Jul 2014 01:11:38 -0000

really love it

Re: The 2014 State of DevOps Report is Here!

Jez Humble — Wed, 04 Jun 2014 16:56:34 -0000

I deleted a comment from someone who posted the direct link. Yes, it's trivially easy to get the direct link and bypass the form. But PuppetLabs put a ton of work into this report and so I'm not going to host a direct link appear on my site.

Re: Patterns

Alec Lazarescu — Thu, 24 Apr 2014 21:02:01 -0000

The handy archive.org works.

Expand/Contract - https://web.archive.org/web...

long-running migrations - https://web.archive.org/web...

Re: Visualizations of Continuous Delivery

Mark Thomas — Wed, 23 Apr 2014 00:55:25 -0000

Love it!! These are going on my wall at work.

Re: Visualizations of Continuous Delivery

Antti Virtanen — Thu, 03 Apr 2014 13:12:44 -0000

You have totally nailed it. This is a awesome summary on the subject and I can't think of anything I would change or remove from it. I can think of many things that could be added, but adding stuff wouldn't make it better.

Re: Visualizations of Continuous Delivery

Nathaniel Eliot — Sun, 16 Mar 2014 15:35:58 -0000

Wonderful. I'm printing these out to go on the wall at work.

Re: Deployment pipeline anti-patterns

Bugsnuffer — Sat, 15 Mar 2014 13:00:48 -0000

While these are good ideas, it's astounding that this is still being meted out in little pearls of wisdom in 2014. Where are the tools that just do all this automatically?? Been using TeamCity lately after years of Jenkins and it's really nice, but still can see hours go up the chute making stuff work that should be super simple.

Re: Visualizations of Continuous Delivery

Patrik Carlos — Thu, 06 Mar 2014 03:54:45 -0000

A great thanks to Nahn for these awesome illustrations. Even I who havent read the book yet have a really good summary. Will defenatelly read it :-)

Re: Visualizations of Continuous Delivery

Kobi Halperin — Wed, 26 Feb 2014 01:02:19 -0000

Thank you for placing these wonderful illustrations here, and special thanks to Nhan for the amazing drawing & visualization talent,
Hope to see more coming on additional topics.
I will surly share these on our local testing forums!
@halperinko - @Kobi Halperin

Re: Visualizations of Continuous Delivery

CraftSteve — Tue, 25 Feb 2014 09:07:55 -0000

These images are awesome. Thank you for producing them - having read the CD book from cover to cover and referring to it over the past 3 years, it is very hard to distill the text into something so accurate and easy to view. Thanks again!

Re: On DVCS, continuous integration, and feature branches

Jez Humble — Mon, 10 Feb 2014 17:57:55 -0000

You can use a release branch for this. I have no problem with release branches, provided they are only used for critical bug fixes.

Re: On DVCS, continuous integration, and feature branches

Jez Humble — Mon, 10 Feb 2014 17:56:48 -0000

In Git (or any DVCS) every developer is *effectively* working on a branch, because until you push your changes to the repo that the canonical builds come out of, you are not integrated.

But @Jilles nowhere says to wait until a feature is complete before merging it into mainline. He says "Push as early as you can. If the CI builds are green on your branch, push and don't wait... Feature branches are not about hiding change but about isolating change." Which I understand is the same as I am proposing, having incomplete features potentially going into production dark.

Re: On DVCS, continuous integration, and feature branches

$247183 — Sun, 09 Feb 2014 00:07:55 -0000

How would this apply to software that needs to release bug fixes before new features are completed?

Re: On DVCS, continuous integration, and feature branches

$247183 — Sat, 08 Feb 2014 23:55:28 -0000

I got confused here, because I see what your article talks about, and what @Jilles describes in his comment as completely different.

I got from your article that you should only have one branch, where you would do all your coding, testing and releasing from. Every programmer would work on that one branch, and would be required to commit to it even when what they are doing is unfinished (feature isn't complete in terms of functionality). To mitigate the problem of having half done features in your product, you would reduce features to very small increment, so that in most cases, committing often will mean committing finished features. Or you would use feature toggles.

I get from his comment that he suggests to use feature branch, but to merge mainline into the feature branches often (FI) and to merge it back to mainline (RI) when the feature is complete and that it has passed testing on it's own branch (which would have been forward integrated with mainline before doing the tests).

Am I understanding things completely wrong?

Re: On DVCS, continuous integration, and feature branches

$247183 — Sat, 08 Feb 2014 23:29:10 -0000

Ya, I wish the author would have talked about this point. When doing feature branch right, you are supposed to merge the mainline into your branch at a minimum every couple of days. So your branch is only a couple of days behind the mainline. Once your feature is complete (the full functionality of the feature is there and devs working on it can't find bugs inside their own environment anymore), you merge from your feature branch into mainline. This merge won't be catastrophic, since it'll only be a couple days old at max.

I'd be curious to know if there are any negatives to this.

Re: There’s No Such Thing as a “Devops Team”

PJ Wysota — Thu, 09 Jan 2014 18:07:02 -0000

Almost got me... You are right at most points... but two:
1. Processes, regardless of how You call them (ITIL, Kanban, "Shitty face" or whatever - happen at organization. The larger organization the more people are involved, and You are faced with situation where You have to trust or You have to control. Both ways are good... untill shit happens - failure or blocking the organization due to overloaded control. Furthermore it is up to organization how they want they process to look like. If organization is going for simplicity - processes may be simple (even with SOX involved). But if they want more control - be prepared for multistaged forms and workflows... It's always about business need, not developer's wishes.
2. I cannot imagine ChM not being able to asses the business/service risk. For me that means he/she does not care about what's going on... Although I've seen a lot in my career, I cannot imagine person, taking care of process (regardless under which framework or concept) that cannot asses risks related with his/her job. FIRE HIM!!! Although, on second thought - it might have happen - just due to simple not understanding what Change Management is actually. From both CHM and developers sides. The simplest test for ChM is any big failure due to human mistake - developer would say it happens. Service oriented person would say - the process went wrong, if we were able to put into production human error. Changes, regardless of way of processing, are to provide SAFE, and OPERATIONAL solutions. Why? Due to fact that most of services, for which You would consider CHM to be in place are bringing the money into organization. e-commerce platforms, webs, e-mails (possibility to communicate). Failure in operations mean failure in earning pennies, means - someone will not get his salary.

and some of my perspective for ChM, devops etc.
1. Releases are changes
2. Any change attached to release is also a change
3. Changes need to be on the safe side - planned (or at least thought of in meaning of how? why? what? when?) untill we do them just to bring stg to life
4. Regardless of model U work with, first rule is: THINK
5. Second rule: DONT RUSH, even if they push U
6. Dont do 10 things at the time - the oldest command rules of Roman Empire Legions was that one commander can manage 5 units max. ABove - he gets lost.
7. If You tke the action - U take responsibility - expect to be blamed, if anything goes wrong
8. Understanding what U doing and what impact does it have is part of Ur f..ng job,
9. If anyone is using things that You want to change - inform prior to change
10. If anyone is making money via things You want to change - involve him - discuss, plan together (get acceptance for ur actions - both of U will be blamed then)
11.Expect unexpected - although tests are for pussies, IT is the only human activity where shit is happening more often just for no reason - testing may show U this sentence is ALWAYS true
12. Simple things are often complex - so dont work with complex ones (they are impossible to handle)
13 (last). Processes are to be performed by PEOPLE, and supported by machines and SW. No process can be performed automatically. That's why do not trust anything U dont control.