Discussing the Cardinal Sin
In this lesson, we will discuss the approach that we were previously using, what was wrong with it and how we are going to rectify the situation.
We'll cover the following...
How did we specify dependencies in Git?
Our applications and their direct third-party dependencies are managed by Jenkins X pipelines. A process is initiated with a push to a Git repository, thus adhering to GitOps principles. If our applications have direct third-party dependencies, we’ll specify them in requirements.yaml. We’ve been doing that for a while, and there is probably no need to revisit the process that works well.
If we move higher into system-level third-party applications, we had mixed results so far. We could specify them as dependencies in environment repositories. If, for example, we need Prometheus in production, all we have to do is define it as yet another entry in requirements.yaml in the repository associated with it. Similarly, if we’d like to deploy it to the staging environment for testing, we could specify it in the repository related to staging. So far, so good. We were following GitOps principles. But, there was one crucial application in this ...