Continuous integration and continuous delivery are both terms we have heard, but what do they really mean? What does CI/CD look like when done well? What are some pitfalls we might want to avoid? In this episode Jérôme and Marko, authors of the book “CI/CD with Docker and Kubernetes” join us to share their thoughts.
Is Changelog CI a new service offering from your favorite news feed providers?! Nope!
Is Changelog CI a way to generate a changelog via carefully crafted PR titles? Yep!
Is auto-generating your project’s changelog a good idea? Maybe…
In this post Arthur covers the core concepts, the question “Should you use GitHub Actions?”, and a step-by-step tutorial to build a functional CI/CD pipeline using GitHub Actions.
If you are already using GitHub to host your project’s source code, getting started with GitHub Actions is effortless. The fact that it integrates fully with the entire GitHub ecosystem means your team can double down on using the platform as a significant part of your software development process.
Overall, my opinion is that GitHub Actions is worth a try. Whether this is the automation system best suited for your team depends on your specific needs.
Jonathan Chang and Michael Deng share all the details of the systems required to deploy at Slack.
Deploys require a careful balance of speed and reliability. At Slack, we value quick iteration, fast feedback loops, and responsiveness to customer feedback. We also have hundreds of engineers who are trying to be as productive as possible. Keeping to these values while growing as a company means continual refinement of our deployment system.
The new changelog.com setup for 2019 is packed with exciting features that are too good to keep to ourselves. Since the infrastructure code is already public and has been running changelog.com for a few months now, the value that we are sharing is proven to us.
An easy guide to the top open source continuous integration, continuous delivery, and continuous deployment tools. It highlights some of the key differentiators of each project, and provides links to additional resources to learn more.
Drew Devault, announcing “sir hat” (or however you want to refer to it)
For those who are new, let me explain what makes sr.ht special. It provides many of the trimmings you’re used to from sites like GitHub, Gitlab, BitBucket, and so on, including git repository hosting, bug tracking software, CI, wikis, and so on. However, the sr.ht model is different from these projects - where many forges attempt to replicate GitHub’s success with a thinly veiled clone of the GitHub UI and workflow, sr.ht is fundamentally different in its approach.
This has folks pretty excited. But what’s all the hubbub about? Well, in addition to being 100% free and open source…
The flagship product from the software suite is it’s CI platform, which:
is easily the most capable continuous integration system available today. It’s so powerful that I’ve been working with multiple Linux distributions on bringing them onboard because it’s the only platform which can scale to the automation needs of an entire Linux distribution.
There’s always a potential for hyperbole when the creator is describing their creation, but I’m convinced this is at the very least worth checking out. It might even make for a great episode of The Changelog…
Sid Sijbrandij and the team at GitLab compared GitLab CI with the three Jenkins variants. Here’s what they learned…
The many plugin combinations for Jenkins has made Legacy Jenkins hard to configure and brittle when updating. Cloudbees is introducing two new versions of Jenkins to remedy the problem: Cloud Native Jenkins will start from scratch, while Jenkins Evergreen will focus on a set of essential plugins. GitLab CI adds new functionality in the main code base, avoiding the need for needless configuration and ensuring everything still works when updating.
Also to note — according to a recent Forrester report GitLab CI and Jenkins/Cloudbees are two of the four leading products for CI.
Travis CI announced the merging of their worlds to combine their .org (open source) and .com (paid) efforts under one roof. Smart move!
Over time we found two platforms lead to confusion for people using travis-ci.org extensively, or together with travis-ci.com … when we decided to move our GitHub integration to GitHub Apps at the beginning of this year, we realized it was a great opportunity to dive into merging travis-ci.org and travis-ci.com into a single platform.