This is the first of many posts highlighting GitOps topics that we’ll be exploring. Within this post, we will explore Helm, a tool used for Kubernetes package management, that also provides templating. Helm provides utilities that assist Kubernetes application deployment. In order to better understand how Helm charts are mapped to Kubernetes manifests, we’ll explain more details below and how to use Helm with and without GitOps.
As some of you may already know, before joining Codefresh I was a Business Process Consultant (BPC) at ServiceNow for their DevOps application. So obviously on my to-do list from day 1 was to create an integration between Codefresh and ServiceNow. In case you’re not familiar with ServiceNow, they’re known for digitalizing enterprise processes and for their portfolio around IT Service Management. In their words, they “Make the world of work, work better for people”.
Is your Helm chart promotion process complicated and difficult to automate? Are rapidly increasing Helm chart versions making your head spin? Do you wish you had a way to quickly and easily see the differences between deployments across all of your environments? If you answered “yes” to any of these questions, then read on! My purpose for writing this article is to share a few of the techniques that I’ve seen make the biggest impact for Codefresh and our customers.
One of the foundations of GitOps is the usage of Git as the source of truth for the whole system. While most people are familiar with the practice of storing the application source code in version control, GitOps dictates that you should also store all the other parts of your application, such as configuration, kubernetes manifests, db scripts, cluster definitions, etc. But what about secrets? How can you use secrets with GitOps?
One of the reasons we define items as code is it allows for the programmatic creation of resources. This could be for infrastructure, for the packages on your machines, or even for your pipelines. Like many of our clients, at Codefresh we are seeing the benefits of an “everything as code” approach to automation. One of the great things about defining different layers in the stack as code is that these code definitions can start to build on each other.
It’s no secret that the software development community is starting to embrace GitOps. With the complexity of engineering modern software today, it is becoming a necessity for many companies to reassess their software development and delivery practices. When Codefresh first released GitOps 2.0 late last year, we had already planned to make it a core pillar of our platform.
The new Codefresh GitOps dashboard gives you the perfect overview of your deployments and how they change over time. This powerful view combines information from multiple sources such as your Kubernetes services, Git Pull Requests, and JIRA issues. To help you incorporate all of this helpful information into your deployments, we have introduced the GitOps controller, a handy agent that is installed in your cluster and collects critical information about your GitOps deployments.
At Codefresh, we are fortunate to hear from customers of all sizes and nearly every industry. A common interest is visibility into deployments and their respective environments. As a company filled with software enthusiasts and developers, this strongly resonates with our culture and our passion for empowering developers. Visibility has been an area of continuous improvement for Codefresh and something we are committed to being the best at.
Microservices are powerful, but it isn’t a secret that they come with many challenges. Codefresh is acutely aware of this as we built our platform on microservices. We know what it means to maintain a fast-moving and complex software service that must remain highly available. One of the most common challenges we deal with is maintaining complex relationships at deployment time among individual microservices.
In our big series of Kubernetes anti-patterns, we briefly explained that static test environments are no longer needed if you are using Kubernetes. They are expensive, hard to maintain, and hard to clean up. Instead, we suggested the adoption of temporary environments that are created on demand when a pull request is opened. In this article, we will see the practical explanations on how to achieve unlimited temporary environments using Kubernetes namespaces.
