![]() With a small difference for feature branches: So for the master branch we’ll have something like this: For feature branches, we'll use the application version with the git SHA as a suffix. It will be equal to the application version for the master branch. The version of the Docker image and the Helm chart will be the same.This way, we allow the version to come from Git and go under the same code review process, just like everything else. The version defined in package.json is leading.To keep our sanity, it makes sense to use a single version number to describe all three versioned components. One important point to remember is that the Helm chart references the desired Docker image version in values.yaml. The version of the Helm chart, as defined in Chart.yaml.The version of the Docker image (or tag in Docker terms).The application version, as defined in package.json.We have various versions that we need to control in our application: In a CD setup, we’d like to be able to deploy any version, from any feature branch, at any given point in time, to any environment (DTAP). But so far, we always deploy the latest version. The Helm chart contains all the information we need to deploy our application to a Kubernetes cluster. In the previous post we created the Helm chart for our hello world blog-helm application.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |