Pass the Take-Home Coding Challenges easily — 2— Automation

Muhammet Arslan
4 min readOct 21, 2021

You finished the code and now time to automate and deploy your application with one click.

Preface

This series will include below articles;

As a reviewer, I would love to see as close as possible to real-life code challenges with the deployment phase. That might include;

  • a MAKEFILE or a shell script to run application and tests
  • a Template Manager Archive — like helm, customize — to make a deployment to a cluster
  • Values files for local and production environments.

Read the job description

Every company uses different technologies. One job description might say;

  • X years experience with container orchestration solutions — Kubernetes is plus
  • Good knowledge of Helm.

Those 2 words already gave you everything you need to do in that step.

So as a developer, after your code is over, by following the below steps, you can handle that issue.

Create a local cluster setup script

Google is full of “how to create a minikube cluster in local” scripts.

Take one, modify it, and put it into your PR under a proper directory — like hack

And never forget to put this detail into README about how to set up this minikube cluster with this script.

Create a full helm template for environments

Please don’t open the PR by saying “assuming you have Redis”, no I don’t, and I cannot create this REDIS dependency for you. I’m expecting you to cover all dependencies for me like you are my peer in the team and opening a PR for a new feature.

So, how to do it better?

  • Create a helm template with two values (or environment) files — Local and Production
  • Create your own dream scenario! For local, you should turn on the toggles for dependencies like redis:true but for production, you can assume redis:false but pass the Redis host value to an AWS ELASTICACHE dummy URL.
  • Create another local setup script under the same directory to let this template be installed to the cluster with one click!

Orchestrate It — High Bonus

Do that and pass it! Believe me, I’ve never seen still from someone who provided some Terraform templates, tough under the dependencies there are;

  • K8s
  • Redis
  • Mysql

If you have time and want to make the company happy and say to them “Hey, I know this job!”, then do that! Believe me, it’s an hour extra thing to do but it is worth so much.

We are not expecting you to cover all cases, like why IOPS is that low, etc, but just show us you know this.

Not: Again read the job description, the company might be using Ansible, Salt or CFN rather than Terraform, so do the orchestration according to that.

Dockerfile

We know everyone can write a Dockerfile, this is not a deal, but not everyone can write a better Dockerfile.

So it’s always good to see that you applied best practices also for Dockerfile, like multi-layer builds or non-root works.

Let’s see these examples;

FROM golang:alpineWORKDIR /app
COPY . /app
RUN go build -o main .CMD ["/app/main"]

Is that wrong? Absolutely not. But It’s what every DOCKER 101 tutorial does, so it’s always better to put something more that makes us feel, “okay they are following or at least having a knowledge about Best Practices”

So let’s add a few more lines to Dockerfile;

# builder image
FROM golang:1.17-alpine as builder
RUN mkdir /build
ADD *.go /build/
WORKDIR /build
RUN CGO_ENABLED=0 GOOS=linux go build -a -o app .

# generate clean, final image for end users
FROM alpine:3.11.3
COPY --from=builder /build/app .

# executable
ENTRYPOINT [ "./app" ]

More information about the best practices of Docker: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

If you like this series, please don’t forget to clap and respond :)

I’ll keep going with new episodes!

Muho!

--

--