Codefresh has recently launched a new certification program that offers organizations and the open-source community a fast track to learning GitOps and how you can apply it to new and existing applications and infrastructure. These certificates can be earned through 3 courses and a final exam.
GitOps has become a buzzword. Developers love it, because it folds DevOps into Git, a frequently used and familiar tool. Using one tool to manage multiple DevOps activities sounds fantastic, and it can be helpful for many. The truth is GitOps has limits. In this article, we explore DevOps and GitOps, compare their similarities and differences, and examine how their principles can work together to support your software development goals.
In our big guide for GitOps problems, we briefly explained (see points 3 and 4) how the current crop of GitOps tools don’t really cover the case of promotion between different environments or how even to model multi-cluster setups. The question of “How do I promote a release to the next environment?” is becoming increasingly popular among organizations that want to adopt GitOps.
If you have been following the Codefresh blog for a while, you might have noticed a common pattern in all the articles that talk about Kubernetes deployments. Almost all of them start with a Kubernetes cluster that is already there, and then the article explains how to deploy an application on top. The reason for this simplification comes mainly from brevity and simplicity. We want to focus on the deployment part of the application and not its infrastructure just to make the article easier to follow.
Several companies nowadays offer a cloud-native solution that manages Kubernetes applications and services. While these solutions seem easy at first glance, in reality, they still require manual maintenance. As an example, an important decision for any Kubernetes cluster is the number of nodes and the autoscaling rules you define.
Have you always wanted to have different settings between production and staging but never knew how? You can do this with Kustomize! Kustomize is a CLI configuration manager for Kubernetes objects that leverage layering to preserve the base settings of the application. This is done by overlaying the declarative YAML artifacts to override default settings without actually making any changes to the original manifest.
Flux is a CNCF based open source stack of tools. Flux focuses on making it possible to keep Kubernetes clusters and cloud-native applications in sync with external resources and definitions hosted in environments such as GitHub. Implementing tools like FluxCD should enable you to achieve results such as: The results above can bring obvious benefits, and many teams are adopting FluxCD as their tool of choice for GitOps.
Matt and I are out in Los Angeles this week for KubeCon 2021 this week. At the GitOpsCon event Tuesday we were excited to attend this Kubernetes session: GitOps in the Real World: Opportunities for Developer Experience Improvement.
In a previous post, we talked about the increasing adoption of Platform Engineering teams. The post covered topics such as defining Platform Engineering and the roles and responsibilities of the team. When building an internal platform, a clear goal that many teams want to achieve is: Even though this is key to a successful platform team, this responsibility increases complexity, costs, support time, and more. Not to mention that this can be a long, very long journey.
Not to muddy the waters with one more prefix in front of ops, GitOps is a newer DevOps paradigm that slants towards the developer. As the names states, GitOps is focused around Git, the source code management tool. As a developer, leveraging an SCM is one of the quintessential tools of the trade; allowing for collaboration and more importantly saving your hard work off of your machine.
