https://devops.jaxlondon.com/blog/devops-conference/the-road-to-continuous-deployment/, posted Mar '17 by peter in continuousdelivery management opinion
It’s a situation many of us are familiar with: a large legacy, monolithic application, limited or no tests, slow & manual release process, low velocity, no confidence… A lot of refactoring is required but management keeps pushing for new features. Now what? We talked to Michiel Rook, a Java/PHP/Scala contractor and consultant about the challenges that walk hand in hand with continuous deployment.
https://blog.skyliner.io/ship-small-diffs-741308bec0d1, posted Feb '17 by peter in continuousdelivery development management opinion
Every line of code has some probability of having an undetected flaw that will be seen in production. Process can affect that probability, but it cannot make it zero. Large diffs contain many lines, and therefore have a high probability of breaking when given real data and real traffic.
https://blog.docker.com/2016/06/docker-1-12-built-in-orchestration/, posted Jun '16 by peter in continuousdelivery deployment docker opensource
Starting with Docker 1.12, we have added features to the core Docker Engine to make multi-host and multi-container orchestration easy.
We’ve added new API objects, like Service and Node, that will let you use the Docker API to deploy and manage apps on a group of Docker Engines called a swarm. With Docker 1.12, the best way to orchestrate Docker is Docker!
This is a long — sorry not sorry! — written piece specifically about the high-level aspects of deployment: collaboration, safety, and pace. There's plenty to be said for the low-level aspects as well, but those are harder to generalize across languages and, to be honest, a lot closer to being solved than the high-level process aspects. I love talking about how teams work together, and deployment is one of the most critical parts of working with other people. I think it's worth your time to evaluate how your team is faring, from time to time.
“We’re trying to be really agile, so we don’t waste time on design or documentation.”
“I have to ship this to production immediately, so I don’t have time to write tests!”
“We didn’t have time to automate everything, so we just deploy our code by hand.”
I don’t know about you, but I’ve always been uncomfortable with Jenkins’ apparent statefulness. You set up your Jenkins server, configure it exactly as you want it, then DON’T TOUCH IT.
Fortunately I now have a solution. With a combination of Docker, Python’s Jenkins API modules, the Jenkins job builder Python module, and some orchestration using docker-compose, I can reproduce my Jenkins state at will from code and run it in isolated environments, improving in iterable, track-able steps.
www.infoq.com/articles/Continuous-Delivery-Maturity-Model, posted Mar '16 by peter in continuousdelivery metrics toread
The principles and methods of Continuous Delivery are rapidly gaining recognition as a successful strategy for true business agility. For many organizations the question is no longer “why?”, but rather “how?” How do you start with Continuous Delivery, and how do you transform your organization to ensure sustainable results. This Maturity Model aims to give structure and understanding to some of the key aspects you need to consider when adopting Continuous Delivery in your organization.
Acts as a proxy for incoming webhooks between your Git hosting provider and your continuous integration server.
When a Git commit webhook is received, the repository in question will be mirrored locally (or updated, if it already exists), and then the webhook will be passed on to your CI server, where it can start a build, using the up-to-date local mirror.
Ashish Kumar presents how Google manages to keep the source code of all its projects, over 2000, in a single code trunk containing hundreds of millions of code lines, with more than 5,000 developers accessing the same repository.
To run a test that asks an important question, that uses a large enough sample size to come to a reliable conclusion, and that can do so amidst a minefield of different ways to be lead astray, takes a lot of resources.
You have to design the test, implement the technology, and come up with the various options. If you’re running a lean organization, there are few cases where this is worth the effort.
Why create a half-assed “A” and a half-assed “B,” when you could just make a full-assed “A?”