#release-engineering (2019-10)
All things CI/CD. Specific emphasis on Codefresh and CodeBuild with CodePipeline.
CI/CD Discussions
Archive: https://archive.sweetops.com/release-engineering/
2019-10-03
2019-10-08
does anyone here use the serverless framework? If so, do you have a CICD pipeline for it(looking for a way to do automated rollbacks upon failure, manual gates for going to prod etc)
Do you know about openFAAS? https://www.openfaas.com/blog/openfaas-cloud-gitlab/
We implemented this with Codefresh
We used approval steps for gates
And implemented unlimited staging environments
@Andriy Knysh (Cloud Posse) can share more
@Adam is one happy camper
@Adam has joined the channel
2019-10-16
@Andriy Knysh (Cloud Posse) I’d love to hear more about this.
i understand this is in a private repo implemented for a customer. We need to discuss with @Adam how to share it
@Brij S we use the serverless framework a lot and are also struggling with CI/CD. I’d love to hear what you’ve come up with so far and how you’re doing branching.
as of now, the best ive got for you is to use github actions and codepipeline
its definitely not the best idea, but it ‘works’
I actually jotted down some notes on serverless and CICD, it’s on my list for an upcoming project coming from one of my dev teams. I’m not sure what part of CICD you’re struggling with, but I think it’s key to decide what resources live with what development lifecycle.
My notes aren’t really good for public consumption since it’s all shorthand, but, the general concept is that you should figure out the demarcation of what serverless manages, and what your other IaC manages. Then your CICD for serverless can become much easier, as it just pulls in dependencies through SSM, or CloudFormation exports, or any number of things.
Here’s a link talking about this by using cloudformation exports as an intermediary: https://theburningmonk.com/2019/03/making-terraform-and-serverless-framework-work-together/
2019-10-17
trying to wrap my head around releasing node apps vs semantic versioning (version change in package.json) and making it simple for developers. Couple ideas, but open for more:
1) with release branch - release is merging from master to release, then use https://github.com/semantic-release/semantic-release to bump version, tag git, and package
2) when developer bumps version in package.json- detect that and release then? Any tooling for this style though?
Any tooling for this style though?
we do something similar and built some custom scripts that track all versions of apps in release with a manifest.
the release captain or lead is responsible for deciding if there’s a semver minor or major bump. the versioning script picks it up and updates
mostly i’m commenting here to get updates on this thread because i’d be interested in hearing more about this.
Mostly agree with @jafow
One other thing I have seen and like is simply to define the release in the code. That way it can be reviewed. Using GitHub actions you can easily enforce that it is modified. Then on merge a release will be cut based on that file
I think developing a heuristic is difficult and mileage may vary
This approach means that you get full control over the semver and easily enforced
Couple this with CODEOWNERS and you also have a way to ensure release captains are involved
Hi @Erik Osterman (Cloud Posse)
like is simply to define the release in the code.
can you please say more about this? do you mean for example defining release in the code by adding a yaml file for your CICD that describes the build/rollout process? Or something else?
No, basically, create a release.txt file with the semver in it
as part of the CI/CD process, upon a merge to master, the pipeline cuts a release corresponding to the value in release.txt
or .release or .github/RELEASE something like that
ah yep I see thanks.
this is interesting workaround
surprised this is not a solved problem by now though… I spent some time googling over weekend and could not find anything ready-made for this
how do you check release.txt was modified ?
In the GitHub action, you would use something like this: https://github.com/nholden/modified-file-filter-action
you can check the list of modified files in the PR to ensure that one of the is the release.txt
This looks pretty close: https://github.com/marketplace/actions/release-drafter
Looks like it supports a .github/release-drafter.yml file
Because cutting a release actually has a lot more metadata than just the version
things like the body of the release
thanks
not a big fan of github actions though (or at least not yet)
How come? What is lacking?
With CircleCi, we can use either a merge or a specific tag to get a release going. It can do the version bump on its own so develop doesn’t have to think about it
2019-10-18
Does anyone pay for Serverless Enterprise?
2019-10-20
2019-10-21
2019-10-22
2019-10-23
here is something that is starting to annoy me, maybe someone here knows about this problem and maybe knows how to fix it, I just started to learn and use Jenkins shared libraries, first loving it one place to make changes in all of my multi repo env my problem is that in every one of my builds I have pollSCM configured (mandatory), and every time I push a new change to my shared library master branch (which is configured in the Jenkins main config), every build I got starts to run if I make changes or add new things I have to wait sometimes 1 hour before the queue clears which is not good, Does anyone maybe know how to fix this problem??
2019-10-24
Only solution I’ve found is to not use pollSCM with Jenkinfile pulled from a separate repo. Options : use web hooks from code repo only or move Jenkinsfile to code repo. PollSCM triggers on any SCM reference in the job. When the Jenkinfile and shared libraries are not directly pulled from SCM by the job, they won’t trigger it
2019-10-30
after adding @Library(value="jenkins_shared_libraries", changelog=false) _ I managed to fix the problem