3 Musketeers for an epic Developer Experience

Sat, 28 Aug 2021 14:18:09 +0000

We all want to reduce toil and improve the developer experience (when starting new applications or joining the team). Developers have had to invest significant time in creating production-ready pipelines when building new products and configuring their workstations when joining teams. Their workstations may not run all the same tests as their pipeline and thus they’re left with #slowfeedback and an inconsistent experience.

The larger the organization (ie Enterprise with 10’s-100’s of teams and applications) the worse the problem gets.

GSD is built on the principle of reusability through a pattern called 3 Musketeers (test, build, and deploy your apps from anywhere, the same way). It gives consistency, control, and confidence to development teams.

Docker is a key part of this pattern, but the use of docker, docker-compose and make together really unlock the powers of consistency, control and confidence in your application build, test and deploy steps. The 3musketeers Docs have some great examples of these patterns.

Here's what the most simple usage looks like:

While the pattern itself is simple, the power (and benefit) comes from the widespread usage across your organization. Here’s what usage might look like:

Agree on a standard interface for all pipeline actions (much like API’s have an agreed interface, all pipelines in the org use the same interface, ie `make build`, `make test`, `make deploy`)
Keep the interface simple (avoid custom pipeline logic, one simple Makefile calls Compose, the container handles all the logic)
Create docker containers for each pipeline step, make them stateless, reuse them where it makes sense

Wins: Modern pipelines already support running steps in docker containers. This pattern extends portability across almost any pipeline tool or development workstation and runs the same way in every single environment. Pipeline steps can be tested independently and reused. This pattern makes it easy to go one step further and generate pipelines on-demand based on boilerplate starter templates. Oh yeah, and #fastfeedback (we’re talking pre-commit).

Info

Also posted on medium as 3 Musketeers for an epic Developer Experience.

Optimizing for DX — The Developer Experience

Sun, 19 Jan 2020 19:18:39 +0000

One thing I’m very much obssessed with is something I’m calling the Developer Experience (DX). I’m literally on a global & lifelong mission to optimize DX.

Hint: Once you’re sold on the benefits of a great DX you can skip ahead to the “3 Steps for success” section.

What is DX and why should you care?

If you’re part of a team/organization that does development then you’re likely going to run into one or more of the following:

Having to keep README’s up to date
Building & testing your code
Bringing new people onto the team & showing them how your code works
Building pipelines & debugging them when they don’t behave
Fixing your dev environment when it breaks
Supporting that one person who wants to use <insert whatever OS the rest of the team isn’t using>
Starting new projects and re-doing the basic building blocks to get started
Trying to support 10 teams all working on their own software but all needing to be able to work closely together (and not re-invent the wheel)

My perfect world!

In a perfect world the mundane parts of development would be simple:

Creating a new project should be fast (I shouldn’t worry about any of the ‘boilerplate’ steps that would be the same between projects)
As a consumer of code: I shouldn’t have to worry about how code is built, tested & deployed
As a developer of code: I should be able to easily update how my code is built, tested & deployed without affecting other developers or build servers wanting to consume my code

If I have to talk to a developer, install some special software dependencies, read a confluence page or README.md, figure out how to get things working on my OS or spend more than 5 minutes getting your software built or a new project setup then you’ve failed to streamline the DX.

3 Steps for success

The’s a concept called 3 Musketeers which is really just an agreed pattern for standardization when building software. It’s most common form uses Make as a standard interface to Compose & Docker Containers but you can adapt the concept to suit your needs.

3 Musketeers
_Test, build, and deploy your apps from anywhere, the same way. Get Started → Run the same commands no matter where you…_3musketeers.io

The net result is a consistent experience that works the same on Windows, Mac & Linux. It’s portable across development machines, build servers and provides consistency that scales from 1 team to 100 teams.

If you’re already using containers in your build server steps or as part of your development then you’re one step closer to a utopia of standardization!

Containers, and the 3 Musketeers concept can be applied any time you need to simplify a process or some instructions. You can consider it “self-documenting”. A good way to check if you’re giving the best DX is to look at what you need to put in your README to explain your process.

No Musketeers

Just

…

Install node version 4 but definitely not version 3, and I have no idea about version 5. I’ve you’re on Windows then I can’t help you at all. There are also a few dependencies that you’ll need but I can’t remember what they were. The following 12 page document is incomplete and you’re about to waste half a day that you’ll never get back.

1 Musketeer — Docker

Just run the following docker command:

docker run --rm -v foo:bar -v foo:bar -e FOO=BAR container bash -c ’echo hello world’

2 Musketeers — Docker & Docker Compose

Just run the following compose command:

docker-compose run --rm alpine echo ‘foo’

3 Musketeers — Docker, Docker Compose & Make

Just run the following make command:

make echo

And it’s as simple as that. Developers typically implement steps like “make build test validate deploy” but you can be as creative as you like and write the steps that make sense for you!

Supercharge your development

Using an agreed pattern like 3 Musketeers is a great way to standardize among your teams. As the number of teams you have in your organization grows so too will the benefits. Humans (and those robot automation scripts) will be able to consume your repos more easily and that’s a great thing.

But why stop there?

What if we could template what a good project looks like and deliver that to development teams in a self-documenting and self-updating fashion?

The most basic implementation of this would be writing a “hello world” application and asking your development copy/paste the code when starting new projects.

But there’s a tool called https://yeoman.io/ and it provides scaffolding for modern web apps. It’s another simple yet impressive concept executed well. What it provides is a templating mechanism with a really slick user-input feature and enough glue in-between to great that amazing DX we’re all chasing.

With yeoman development teams can setup and maintain examples of good software delivery with teams benefiting from the learnings of others. You can create a generator for just about anything, so the only thing left is your imagination!

Yeoman has it’s own generator to help you create your first generator (how meta, right?). The only thing missing for me was a reliable docker container to do some development in. I created a repo with a yeoman development container to make life easier. Hopefully you find it useful and make some steps to improve your own DX!

drewkhoury/devyo
_yeoman container - for local development of yeoman generators - drewkhoury/devyo_github.com

Want more?

Presentation (PDF): Optimizing for DX in a Cloud Native world
Presentation (Video): https://www.youtube.com/watch?v=ZYlbNnaoseI