Good Software Delivery (GSD) is the term we use for the set of practices that help deliver, well, good software. There’s a focus on short feedback loops, a consistent developer experience, with more time spent delivering and less time spent on chores like workstation setup and debug.
For context, I’ve previously written the following blogs that explain a lot of the “why” you’d want to implement the app I’m about to demo:
Assumptions
Before we dive in I want to share my assumptions and expectations. This blog/demo is aimed at developers, who are also familiar with pipelines, local development environments, and tools like docker.
While you can clone the repo and run the commands quickly (even with zero knowledge or experience in the underlying Golang app), it will take you longer than 30 seconds to read this blog, and even longer to look through the repo’s README.md and code in the repo to see what’s happening when you type each command. I’ve tried to add as much detail and context for those that’d like to deep dive, both in this blog and in the repo itself.
The purpose isn’t to copy and paste what you see here into production, but I do hope I’m able to demonstrate some ways of setting up your repo and local development environment in a way that could save you and your team time for your next product!
What we’ll do in this demo
In this post, I wanted to share a hands-on implementation of some of these concepts that you can try for yourself. We’ll be using a hello-world app written in Golang, and by the end of the demo I’m hoping:
- You’ll see how wrapping our pipeline in 3 Musketeers can greatly reduce the amount of toil spent getting a new project started (thus the 30 seconds claim for this simple app)
- You’ll see that you can adapt the concepts in this demo to just about any app (Java, .Net etc) — More complex apps may take longer to compile, but no extra effort should be required in terms of desktop setup (toil)
- You’ll be able to extend the logic for other pipeline tasks like testing or security
If this demo takes you longer than 30 seconds to run this demo, I suspect:
- We need to get you a better Internet connection (most of the 30 seconds for me is spent downloading the initial Golang image on an empty docker cache)
- We need to help you with the base requirements that this blog assumes you already have (
make,dockeranddocker-compose)
In any case, reach out on LinkedIn if you have suggestions to improve this demo, or set up a virtual meeting with me if you’d like a 1:1 workshop/chat!
The demo (build and run a Go app in 30 seconds)
At a minimum, you’ll need
_make_,_docker_and_docker-compose_on your workstation. See requirements for more info or continue on if you’ve already got these.
Not sure about running this demo on your computer? Never fear! You can use this online environment from the safety of your browser: GSD HelloWorld katacoda (repo will already be cloned in this environment, with required software ready to go)
You can see all of my Katacoda courses at https://www.katacoda.com/drewkhoury/.
- Clone the repo: Start by cloning the GSD HelloWorld repo:
git clone git@github.com:contino/gsd-hello-world.git && cd gsd-hello-world
2. Build the app: Once you have the codebase, build the app using:
make build
This step will create a build artifact (in our case, a docker image) by doing the following:
- downloads the appropriate docker image onto your workstation
- copies the source for our app into the image
- builds the application in the image
- configures the port/cmd to be used at runtime
3. Run the app: Now that you have your build artifact handy, you can run the application locally with:
make run
This step will run/deploy the artifact on your workstation by doing the following:
- uses docker to create a container based on the image from the
buildstep - exposes port 8080 locally
- the docker image runs the cmd
./mainwhich starts the application for us
That’s it, you’re running the GSD HelloWorld application written in Golang and containerized so that it can quickly be deployed in Docker.
Bonus: You can run make test to execute the test suite (note this may legitimately fail if it doesn’t meet the testing threshold), andmake down to clean up once you’re done.
The beauty of this model is in its simplicity. We’re using make as the interface and we’re running all the tasks in containers to ensure consistency. It’s easy enough to peak under the hood to see what either of those tools is doing, and this runs just as easily on your workstation as it does on your CI tool of choice.
Digging into the code
To keep this section brief I’m going to assume some prior knowledge around development, docker, and make.
What if I want to make my own changes or do something similar in my own repo?
For the curious: Checkout the Makefile, docker-compose.yml and Dockerfile in the repo. These drive our pipeline and app build etc, and while they abstract the complexity away from day-to-day usage, they’re intended to be developer-friendly in terms of understanding exactly what each step is doing.
Building the app: For example make build is what builds our application, and in the Makefile you’ll see it does the following:
docker build -t ${FULL_TAG} .
Replacing the app: If you wanted to replace our Golang application with your own Java application, you’d drop in your own Dockerfile , replace the /src, and leave everything else as-is. The beauty is that any developer using the repo still runs make build and they don’t need to worry about Go vs Java dependencies (or in theory even know that you completely rewrote the application) — it just works™.
Note: This repo is a testing ground for GSD practices — simple but powerful ways to supercharge your development.
If you’d like to see what else you can do, have a look at the rest of the https://github.com/contino/gsd-hello-world — we have plenty for you to explore.
-
build,testandrunactions are driven by a simpleMakefile— with underlying execution via docker containers - Build badge in README.md
- Repo Visualization in README.md
- Sonar quality, reliability, and security badges in README.md
- Golang security in-pipeline
- Local tests via
make test - Artifact storage via Github Packages
- Github Actions
- Deployment to k8s in GCP
Further reading:
May your software be good, and your delivery be continuous — drew
Also posted on medium as How to implement Good Software Delivery in 30 seconds.
Oldest comments (0)