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.
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.
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.
Microsoft has begun working with the Docker team and community so Docker can be used for the following: If you would like to run an ASP.NET Core web app in a Docker container and learn how to create images, we will explain all the steps on how to do the following: A Docker container image is a standalone, lightweight package that can be executed and contains all the requirements you need to run an application, such as: code, runtime, libraries, and settings.
If you are trying to learn your way around Continuous Integration/Delivery/Deployment, you might notice that there are mostly two categories of resources: We believe that there is a gap between those two extremes. We are missing a proper guide that sits between those two categories by talking about best practices, but not in an abstract way.
This is the second part in our “Enterprise CI/CD best practices” series. See also part 1 for for the previous part and part 3 for the next part. You can also download all 3 parts in a PDF ebook.
