Inner Loop vs Outer Loop

https://opensource.com/article/21/6/open-source-developer-tools

inner loop是开发者的最常做的事情， 编码 运行 验证 调试

outer loop是我们经常提及的CI/CD， 从代码提交入库， 到CI进行测试，测试通过后构建，构建成功后， 进入CD， 或者发布版本， 或者在发布后部署到产品环境中。

 

The industry is still working on perfecting how a developer's time is spent. We can divide a developer's major tasks into two different "loops":

• Inner loop: These are the most common tasks developers do, the ones that fully utilize their skillsets: code, run, validate, and debug. This is the classical developer loop.

innerloop.png

^{(Nimisha Mukherjee, CC BY-SA 4.0)}

• Outer loop: This is where a developer's code goes through continuous integration and continuous delivery (CI/CD) and gets deployed to production. On Gitlab and similar platforms, a developer's pull request (PR) gets merged to the main branch, CI/CD kicks in and creates the build, runs the necessary tests, and deploys to the specified environments. This is a DevOps loop.

outerloop.png

 

 

docker practice

https://docs.docker.com/ci-cd/best-practices/

docker一般被认为是部署工具

即， 在开发者开发完毕代码， 提交到版本库中， 自动进行测试 构建 部署的过程。

但是这并不符合 DEVOPS文化， 其要求开发者的开发环境 和 部署环境要求一致。

所以docker 就提供了 这种功能， 在本地开发者可以通过构造与部署相同的容器环境，在此环境中进行本地化的构建和测试。

 

Inner and outer loops

To get started, one of the most important things when working with Docker and any CI/CD is to understand when you need to test with the CI, and when you can do this locally. At Docker, we think about how developers work in terms of their inner loop (code, build, run, test) and their outer loop (push changes, CI build, CI test, deployment).

Before you think about optimizing your CI/CD, it is important to think about your inner loop and how it relates to the outer loop (the CI). We know that most users don’t prefer ‘debugging through the CI’. Therefore, it is better if your inner loop and outer loop are as similar as possible. We recommend that you run unit tests as part of your docker build command by adding a target for them in your Dockerfile. This way, as you are making changes and rebuilding locally, you can run the same unit tests you would run in the CI on your local machine using a simple command.

The blog post Go development with Docker is a great example of how you can use tests in your Docker project and re-use them in the CI. This also creates a shorter feedback loop on issues and reduces the amount of pulls and builds your CI needs to do.

 

docker技术点

https://docs.docker.com/develop/develop-images/multistage-build/

在dockerfile中支持多target定义。

 

# syntax=docker/dockerfile:1
FROM golang:1.16 AS builder
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go    ./
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /go/src/github.com/alexellis/href-counter/app ./
CMD ["./app"]  

运行只运行其中一个target

 docker build -t alexellis2/href-counter:latest .

样例

https://www.docker.com/blog/containerize-your-go-developer-environment-part-1/

https://www.docker.com/blog/containerize-your-go-developer-environment-part-2/

在dockerfile中定义 unittest test

# syntax = docker/dockerfile:1-experimental

FROM --platform=${BUILDPLATFORM} golang:1.14.3-alpine AS base
WORKDIR /src
ENV CGO_ENABLED=0
COPY go.* .
RUN go mod download
COPY . .

FROM base AS build
ARG TARGETOS
ARG TARGETARCH
RUN --mount=type=cache,target=/root/.cache/go-build \
GOOS=${TARGETOS} GOARCH=${TARGETARCH} go build -o /out/example .

FROM base AS unit-test
RUN --mount=type=cache,target=/root/.cache/go-build \
go test -v .

FROM scratch AS bin-unix
COPY --from=build /out/example /
...

 

在makefile中定义unittest target， 对应docker build unittest

all: bin/example
test: unit-test

PLATFORM=local

.PHONY: bin/example
bin/example:
    @docker build . --target bin \
    --output bin/ \
    --platform ${PLATFORM}

.PHONY: unit-test
unit-test:
    @docker build . --target unit-test

 

K8S for INNER LOOP

https://medium.com/geekculture/developing-on-kubernetes-the-inner-outer-loop-6957f9597f7a