#release-engineering (2018-08)
All things CI/CD. Specific emphasis on Codefresh and CodeBuild with CodePipeline.
CI/CD Discussions
Archive: https://archive.sweetops.com/release-engineering/
2018-08-01

@Phil has joined the channel

@my-janala has joined the channel

@Ziad Hilal has joined the channel
2018-08-05

@jylee has joined the channel
2018-08-08

@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

2018-08-09

@dat.le has joined the channel
2018-08-16

@Max Moon we are about to merge https://github.com/cloudposse/build-harness/pull/85
What Use helm package to change version and app Version of chart Use convention that default image tag is based on app Version Create promote targets that allow to promote chat to required versio…

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)

2018-08-17

@antonbabenko has joined the channel
2018-08-18

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)
2018-08-19

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.

what add monochart (moved from helm-chart-scaffolding) references #5 #6 #8 #9

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”?

nothing comes to mind, but looks like you are picking bats-core

?

haha

yea - just needed to move forward to something. still in the prototyping phase. it can be replaced with something else.

seems like it’s no longer maintained

bats - Bash Automated Testing System

though looks like bats-core
is maintained

bats-core - Bash Automated Testing System

Travis is using bats

terraform-config - Terraform bits and bytes

@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

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

- testing helm/helmfiles

- 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.