#release-engineering (2018-08)

@Phil has joined the channel

@my-janala has joined the channel

@Ziad Hilal has joined the channel

@jylee has joined the channel

@Michael Pereira has joined the channel

@michal.matyjek +1 for hadolint as I believe it’s based on the excellent shellcheck, which makes sense since Dockerfile are mostly just a collection of shell commands

so it benefits from the existing shellcheck rules

@dat.le has joined the channel

@Max Moon we are about to merge https://github.com/cloudposse/build-harness/pull/85

This adds the ability to promote images and charts between repositories

We suggest adopting this as your production strategy

There are some minor breaking changes which @Igor Rodionov will document

(related to renamed ENVs)

@antonbabenko has joined the channel

On this topic - maybe it’s my misunderstanding of helm? but kinda bothers me that chart version would rev with appVersion (they don’t have to match of course). Or is it OK to keep these decoupled in say, dev, and only revision chart version on promoting to staging/production? Don’t use appVersion in charts at all? What’s the right strategy?

(this is loosely related to the PR above)

but kinda bothers me that chart version would rev with appVersion (they don’t have to match of course).

@michal.matyjek this strategy is designed for repos where we cotenant the chart with the app itself. if the chart is not hosted in app repo, then it’s a much more difficult problem to solve.

I don’t see the benefit of treating an app as a “monorepo” just because it also contains a chart. that is, treating the “chart” as one app, and the service itself as another “app”. If the chart and app are in the same repo, then they are the same version IMO.

that said, we’re investing now in a monochart.

https://github.com/cloudposse/charts/pull/155

this is one chart to rule them all.

it’s still a WIP with lots of comments. @alebabai is working on it.

The idea is to get out of the business of writing charts and just defining values.yaml

…to stop allowing every service to be a snowflake and instead take the Heroku approach where you write a service that conforms to certain principals and then the monochart just works.

Plus, the monochart is composable, so you can create a service with multiple components just by creating an umbrella chart

@alebabai has joined the channel

@michal.matyjek any recommendations for alternatives to “bats”?

seems like it’s no longer maintained

https://github.com/sstephenson/bats

though looks like bats-core is maintained

https://github.com/bats-core/bats-core

Travis is using bats

https://github.com/travis-ci/terraform-config/blob/master/runtests

@Sebastian Nemeth heads up, i’ve spent some time this weekend working on a prototype for testing #geodesic

@Sebastian Nemeth has joined the channel

Submitted some PRs against geodesic to make it easier

For now, I’m going to be using Codefresh because it’s easier to iterate than using codebuild/codepipeline

as it relates to infrastructure, I see it boils down to a few different use-cases

1. testing terraform modules (including terraform-root-modules)

1. testing helm/helmfiles

1. testing account-level infrastructure

for our purposes, I’ve ruled out atlantis and test kitchen, at least at this phase. I want something that lets us test more holistically, since what we need to test is the integration of lots of systems across languages, tools, and binaries.

for this reason, I am leaning towards using bats (bats-core) - or a tool like it

bats-core feels very lightweight, which I like.

bash as a “top most level” language for integration also feels right. it doesn’t preclude us using other purpose-built testing frameworks for individual languages or apps.