You need two things to effectively move fast: a culture of psychological safety and smart investments in tooling. Employees need to feel empowered to speak up if things are moving too fast—if they are concerned about why a feature is being built and to identify gaps in the processes. They need to feel they won’t be blamed when something breaks. Building this requires empathy, open communication, and teamwork. This psychological safety is the foundation of being able to move quickly and quickly recover when things break.

Next up is selecting the right tooling and processes. Invest in tools that make things easier. Tools should be useful, usable, and change the underlying problems, not create more.

I’ve used the term *Feature Factory* at a couple conference talks over the past two years. I started using the term when a software developer friend complained that he was “just sitting in the factory, cranking out features, and sending them down the line.”

How do you know if you’re working in a feature factory?

Most web apps need login information of some kind, and it is a bad idea to put them in your source code where it gets saved to a git repository that everyone can see. Usually these are handled by environment variables, but Docker has come up with what they call Docker secrets. The idea is deceptively simple in retrospect. While you figure it out it is arcane and difficult to parse what is going on.

When you are solving a difficult problem re-ask the problem so that your solution helps you learn faster. Find a faster way to fail, recover, and try again. If the problem you are trying to solve involves creating a magnum opus, you are solving the wrong problem.

Vanna is an internal feature flagging service used at PBS. It helps deliver new features to users quickly and safely. This is an example client implementation for browser based Javascript.

More info in this article at Dev.to.

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.

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.

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.”

1–10 (26)   Next >   Last >|