#release-engineering - July 2018 | Slack Archive

release-engineeringArchived

108 messages

CI/CD Discussions

Archive: https://archive.sweetops.com/release-engineering/

July 2018

Aug 2018

erikover 7 years ago

@Erik Osterman (Cloud Posse) has joined the channel

erikover 7 years ago

set the channel description: CI/CD Discussions

Rohit Vermaover 7 years ago

@Rohit Verma has joined the channel

Igor Rodionovover 7 years ago

@Igor Rodionov has joined the channel

Jeremy G (Cloud Posse)over 7 years ago

@Jeremy G (Cloud Posse) has joined the channel

Max Moonover 7 years ago

@Max Moon has joined the channel

Dave Yuover 7 years ago

@Dave Yu has joined the channel

Jonathan Olsonover 7 years ago

@Jonathan Olson has joined the channel

Andriy Knysh (Cloud Posse)over 7 years ago

@Andriy Knysh (Cloud Posse) has joined the channel

Evan Petrieover 7 years ago

@Evan Petrie has joined the channel

Erik Osterman (Cloud Posse)over 7 years ago(edited)

@Rohit Verma

how to use semantic versioning, I actually couldn't figure out how to start from a specific version. We have created charts in a repo under path charts/. I have write a make step to detect the charts which are changed. I want to automatically increment their semantic version. Is this something which can be achieve by this module. What I found is it generates semantic version as 0.0.0-sha(commit-id)

Erik Osterman (Cloud Posse)over 7 years ago

We follow the convention of tightly coupling charts with the micro service. We stick them in the the charts sub folder. The calculus of knowing which charts work with with docker images is a lost cause. The official chart repo by Kubernetes is optimizing a different use case, which is why they have all charts in one repo. The semantic version of our charts is derived from the nearest git tag in the tree. So if no previous tags, then you get 0.0.0.

Erik Osterman (Cloud Posse)over 7 years ago

We have some documentation on our process here: https://docs.cloudposse.com/release-engineering/cicd-process/semantic-versioning/

Erik Osterman (Cloud Posse)over 7 years ago

(with codefresh)

erikover 7 years ago

set the channel topic: All things CI/CD. Specific emphasis on Codefresh and CodeBuild with CodePipeline.

Erik Osterman (Cloud Posse)over 7 years ago(edited)

@Igor Rodionov is working on a way to promote charts and images between repos (for @Jeremy G (Cloud Posse))

Rohit Vermaover 7 years ago

the rational of defining charts in a separate repos are
1. Encapsulate ops from devs (both code and structure wise)
2. Within dev.niki.ai we have the required service/helmfile with image tags, which makes sense to us to syncup whole infra from one repo
3. The infra-changes (including services) can be monitored in one Pull request
4. Even we can move chartmuseum to gitlab pages in future, or if we got a chance to free chart hosting service, it can be synced up using 1 repo only

Erik Osterman (Cloud Posse)over 7 years ago

Encapsulate ops from devs (both code and structure wise)

Rohit Vermaover 7 years ago

What I was looking up from SEMVER is a way to incrementally update the semantic version only

Erik Osterman (Cloud Posse)over 7 years ago

isn't that antithetical from devops?

Rohit Vermaover 7 years ago

i think restriction is unethical, encapsulation is not

Erik Osterman (Cloud Posse)over 7 years ago

i want the developers to write the charts to deploy their apps

Erik Osterman (Cloud Posse)over 7 years ago

i'll write one as an example, they write the rest

Erik Osterman (Cloud Posse)over 7 years ago

when their app architecture changes, I won't know

Erik Osterman (Cloud Posse)over 7 years ago

they should update the chart respectively

Rohit Vermaover 7 years ago

I never mentioned that dev’s shouldn’t commit on other repos, but this won’t be as frequent as the code commits

Erik Osterman (Cloud Posse)over 7 years ago

i think the semver stuff will work though for your use case anyways

Erik Osterman (Cloud Posse)over 7 years ago

but versioning your charts will be manual

Rohit Vermaover 7 years ago

even that is also one point,
5. Seperate pipelines for charts and code

Erik Osterman (Cloud Posse)over 7 years ago

the same way they are versioned in kubernetes/charts

Erik Osterman (Cloud Posse)over 7 years ago

but the pipeline will generate the semvers for the docker containers

Erik Osterman (Cloud Posse)over 7 years ago

and will pass that to the chart as the image tag to deploy

Erik Osterman (Cloud Posse)over 7 years ago

our strategy has been to pin charts to containers

Erik Osterman (Cloud Posse)over 7 years ago

that way for every single version on an app, there's a chart that will deploy it

Erik Osterman (Cloud Posse)over 7 years ago

makes it very easy to maintain and understand what's going on. departing from that will introduces new challenges.

Rohit Vermaover 7 years ago

in place of pinning to charts, i think this it should be pinned to helmfile

Rohit Vermaover 7 years ago

version of charts is entirely separate thing than version of code

Erik Osterman (Cloud Posse)over 7 years ago

but there's no artifact storage for helmfiles

Rohit Vermaover 7 years ago

it can still be managed in same way, using yq

Erik Osterman (Cloud Posse)over 7 years ago(edited)


  - name: '{{ env "RELEASE_NAME" }}'
    labels:
      chart: "somechart"
      component: "app"
    version: '{{ env "CHART_VERSION" }}'
    chart: 'chart-repo/{{ env "CHART_NAME" }}'
    namespace: '{{ env "NAMESPACE" }}'
    values:
      - '{{ env "RELEASE_NAME" }}.yaml'

Erik Osterman (Cloud Posse)over 7 years ago

so that's the helmfile from a microservice that says how to deploy it

Erik Osterman (Cloud Posse)over 7 years ago

the envs come from the pipeline

Rohit Vermaover 7 years ago

you could add image tag also as part of set

Erik Osterman (Cloud Posse)over 7 years ago

yep

Erik Osterman (Cloud Posse)over 7 years ago(edited)

so that's the way to do it if you want to decouple the charts from the service repo

Rohit Vermaover 7 years ago

the point is that, charts represent how a service should run infrastructure wise, but not what a service is running

Rohit Vermaover 7 years ago

what a service is, its being defined by container

Erik Osterman (Cloud Posse)over 7 years ago

something similar could be said for the Dockerfile, no?

Erik Osterman (Cloud Posse)over 7 years ago

OS ~~Dockerfile~~ service

Rohit Vermaover 7 years ago

not at all, its all about how we package the service

Erik Osterman (Cloud Posse)over 7 years ago

cluster ~~chart~~ docker

Rohit Vermaover 7 years ago

service ~~Dockerfile | cluster~~ chart | release ~ version

Rohit Vermaover 7 years ago

services are tightly coupled with dockerfile, we can’t use one service’s dockerfile for another

Erik Osterman (Cloud Posse)over 7 years ago

if using a monochart (declarative helm chart) for multiple services, i think it makes sense to move it out

Erik Osterman (Cloud Posse)over 7 years ago

but if a chart is 1:1 to a service, there's no overwhelming reason to separate them

Rohit Vermaover 7 years ago

to be frank we are not using monochart but the same replica of chart for each service

Rohit Vermaover 7 years ago

just in case we need to modify something

Rohit Vermaover 7 years ago

its like we have 3 charts

Rohit Vermaover 7 years ago

external, internal, job

Rohit Vermaover 7 years ago

all external services had just required external chart, nothing else

Rohit Vermaover 7 years ago

all internal services require internal chart

Erik Osterman (Cloud Posse)over 7 years ago

but our differences aside, I think doing what you said with passing the image tag in the helmfile from an ENV

Rohit Vermaover 7 years ago

and same for jobs

Erik Osterman (Cloud Posse)over 7 years ago

will accomplish what you want in the end, no?

Rohit Vermaover 7 years ago

kind of, its more of doing a git commit on service updates within helmfile

Erik Osterman (Cloud Posse)over 7 years ago

(i want to move to a monochart for new services so they all follow a similar architecutre)

Rohit Vermaover 7 years ago

yeah but everything apart => I doubt we have a function which do this, Input => 1.0.0 Output => 1.0.1

Erik Osterman (Cloud Posse)over 7 years ago

yea, we don't do that

Erik Osterman (Cloud Posse)over 7 years ago

knowing when to bump versions I think requires a human

erikover 7 years ago

Erik Osterman (Cloud Posse)over 7 years ago

our semantic versioning takes the x.y.z from the most recent tag

Erik Osterman (Cloud Posse)over 7 years ago(edited)

and computes metadata based on branch information (for staging environments)

Erik Osterman (Cloud Posse)over 7 years ago

(so what we're doing is really not that magical at all)

Arkadiyover 7 years ago

@Arkadiy has joined the channel

Erik Osterman (Cloud Posse)over 7 years ago

@Yoann https://codefresh.io/continuous-integration/codefresh-versus-gitlabci/

Yoannover 7 years ago

@Yoann has joined the channel

Max Moonover 7 years ago

just a heads up, if anyone else had the "CodeFresh" status check as a passing requirement for PRs, it is no longer. Now your PR will get a status update that is pipeline specific. If you have repos that require the CodeFresh status, disable it in favor of Pipeline status

Erik Osterman (Cloud Posse)over 7 years ago

thanks @Max Moon! didn’t know that.

Erik Osterman (Cloud Posse)over 7 years ago

@Dave Yu @Jonathan Olson ☝️

Max Moonover 7 years ago

NP!

Michal Matyjekover 7 years ago

@Michal Matyjek has joined the channel

Erik Osterman (Cloud Posse)over 7 years ago

@Michal Matyjek not sure if this is too complicated of a PR for you take an interest in

Erik Osterman (Cloud Posse)over 7 years ago

https://github.com/cloudposse/build-harness/pull/85

Erik Osterman (Cloud Posse)over 7 years ago

but we are working on the ability to easily/cleanly promote images and charts between repositories

Erik Osterman (Cloud Posse)over 7 years ago(edited)

The goal is to be able to do something like


make release/promote \
    CHART_NAME=api-app \
    SOURCE_VERSION=0.1.0 \
    TARGET_VERSION=0.2.0 \
    SOURCE_IMAGE=api-app:0.1.0-sha.a989ads8 \
    TARGET_IMAGE=api-app:0.2.0

Michal Matyjekover 7 years ago

yeah

Erik Osterman (Cloud Posse)over 7 years ago(edited)

(interface not yet formalized)

Michal Matyjekover 7 years ago

we're not there yet but the more I think about it - this seems to be the way to go

Erik Osterman (Cloud Posse)over 7 years ago

are you guys using multiple codefresh accounts?

Michal Matyjekover 7 years ago

we are not

Erik Osterman (Cloud Posse)over 7 years ago

that also seems like a must have

Michal Matyjekover 7 years ago

elaborate?

Erik Osterman (Cloud Posse)over 7 years ago(edited)

it’s the only way to RBAC production kubernetes integration from staging clusters kubernetes integration

Michal Matyjekover 7 years ago

on what you posted - in our flow we may do this for releases, for "master" CI we would autoversion

Michal Matyjekover 7 years ago

RBAC - waiting for CF to implement, on our "must-have" list, last I heard it is in progress

Erik Osterman (Cloud Posse)over 7 years ago

multi-account is available now I thought

Erik Osterman (Cloud Posse)over 7 years ago

so you setup all produciton pipelines in the production account

Erik Osterman (Cloud Posse)over 7 years ago

all staging pipelines in the other account

Erik Osterman (Cloud Posse)over 7 years ago

that way staging pipelines can never accidentally modify production

Michal Matyjekover 7 years ago

yeah makes sense

Max Moonover 7 years ago

https://codefresh.io/codefresh-news/codefresh-adds-unified-support-multi-git-provider-accounts/?utm_source=app&medium=intercom

Michal Matyjekover 7 years ago

Anyone using dockerfile linter they can recommend?

Erik Osterman (Cloud Posse)over 7 years ago

A ways back, I had looked into it and didn’t find one that I liked, but that was partially because they were all in either python or ruby.

Erik Osterman (Cloud Posse)over 7 years ago

If you find one you like, lmk! Would love to add it to our own build harness. I might concede on the ruby/python now :-)

Michal Matyjekover 7 years ago

I don't think twistlock can do the level of linting we would prefer, so looking for something. I did not realize there are so many (simple google search shows 4-5 right away)

Erik Osterman (Cloud Posse)over 7 years ago

Also do a GitHub repo search

Erik Osterman (Cloud Posse)over 7 years ago

@Rohit Verma have any linting suggestions

Michal Matyjekover 7 years ago

Looked at 4-5 docker linters I could find and ran our one of our Dockerfile through them.
The two that I liked the most are https://github.com/RedCoolBeans/dockerlint and https://github.com/hadolint/hadolint - the only 2 that complained about the non-array-style CMD or ENTRYPOINT

https://github.com/hadolint/hadolint seems well maintained (last updated 8 days ago) has most stars and forks

I also like the configuration and per-line excludes.

No earlier messagesBrowse by date August 2018