Create Jenkinsfile to deploy UI code to S3 bucket.
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)
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
@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/
The Serverless framework is the most popular deployment framework for serverless applications. It gives you a convenient abstraction over CloudFormation and some best practices out-of-the-box: Filters out dev dependencies for Node.js function. Update deployment packages to S3, which lets you work around the default 50MB limit on deployment packages. Enforces a consistent naming convention for … Making Terraform and Serverless framework work together Read More »
Learn how to provision your own OpenFaaS Cloud on Kubernetes connected to a self-hosted GitLab instance on any public or private cloud within 100 seconds.
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:
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
.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
Modified File Filter for GitHub Actions. Contribute to nholden/modified-file-filter-action development by creating an account on GitHub.
you can check the list of modified files in the PR to ensure that one of the is the
This looks pretty close: https://github.com/marketplace/actions/release-drafter
Drafts your next release notes as pull requests are merged into master
Looks like it supports a
Because cutting a release actually has a lot more metadata than just the version
things like the body of the release
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
Does anyone pay for Serverless Enterprise?
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??
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
@Library(value="jenkins_shared_libraries", changelog=false) _ I managed to fix the problem