Update some docs related to cicd and branching.

docs/branching-strategy.md

@@ -1,28 +1,28 @@
 # Universal Resolver — Branching Strategy
 
 The goals for our branching strategy are:
-* The master-branch should be deployable at any time. This implies a stable build and the assurance that the core-functionality is provided at any time when cloning the master.
-* The master-branch should stay active. As collaboratively working with multiple developers, we encourage merging the code as frequently as possible. This will potentially disclose issues at an early stage and facilitate the repair. Furthermore, it makes clear that the master-branch is the preferred choice that newcomers want to clone.
+* The `main` branch should be deployable at any time. This implies a stable build and the assurance that the core-functionality is provided at any time when cloning the `main` branch.
+* The `main` branch should stay active. As collaboratively working with multiple developers, we encourage merging the code as frequently as possible. This will potentially disclose issues at an early stage and facilitate the repair. Furthermore, it makes clear that the `main` branch is the preferred choice that newcomers want to clone.
 * In order not to waste time the branching strategy should stay as simple as possible.
 
 Among a bunch of various strategies we have chosen *GitHub Flow*, which is a lightweight branching-strategy encouraged by the GitHub dev-teams. Details can be found here: https://guides.github.com/introduction/flow/
-The following recipe shortly describes the typical steps that developers need to be take into account when updating the code base: 
+The following recipe shortly describes the typical steps that developers need to be take into account when updating the code base:
 
 ![](https://hackernoon.com/hn-images/1*iHPPa72N11sBI_JSDEGxEA.png)
 
-1. ***Create a branch***: When implementing a new feature, some improvement or a bugfix, a new branch should be created of the master-branch. In order to preserve an organized git-repo, we agreed on follwing prefixes for branches:  
+1. ***Create a branch***: When implementing a new feature, some improvement or a bugfix, a new branch should be created of the `main` branch. In order to preserve an organized git-repo, we agreed on follwing prefixes for branches:
 
     - feature-\<branch-name\> -> adding/changeing functionality, whereas the branch-name should reflect the intention
     - bugfix-\<GitHub-issue\> -> fixing Github-issues
-    - refactor-\<branch-name\> -> cleanup, maintanance, improving code quality, adding Unit tests  
-    - ci-\<branch-name\> -> anything related to continous integration  
+    - refactor-\<branch-name\> -> cleanup, maintanance, improving code quality, adding Unit tests
+    - ci-\<branch-name\> -> anything related to continous integration
     - docs-\<branch-name\> -> updating/extending documentation, no code changes allowed  
-    - release-\<version-to-be-released\> -> release of a new major version  
+    - release-\<version-to-be-released\> -> release of a new major version
 
     Feature branches are the most inclusive, which can contain refactoring and documentation.
     Always use the GitHub-issue name as part of the branch-name, if there is a corresponding issue available.  
 
 2. ***Commit some code***: Add your changes to the new branch and commit regularly with a descriptive commit-message. This builds up a transparent history of work and makes a roll back of changes easier.
-3. ***Open a Pull Request (PR)***: Once your changes are complete (or you want some feedback at an early stage of development) open a PR against the master-branch. A PR initiates a discussion with the maintainer, which will review your code at this point. Furthermore, the [[CI/CD process|Continuous-Integration-and-Delivery]] will be kicked off and your code will be deployed to the dev-system. 
-4. ***Discuss, review code and deployment***: Wait for feedback of the maintainer and check the deployment at the dev-system. In case of contributing a new driver the maintainer will also add the deployment-scripts in the scope of this PR. You may also be requested to make some changes to your code. Finally, the new changes should be safely incorporated to the master-branch and the updated universal-resolver is running smoothly in dev-environment.
-5. ***Merge to the master-branch***: If all parties involved in the discussion are satisfied, the maintainer will merge the PR into the master-branch and will close the PR itself. You are free to delete your branch as all changes have already been incorporated in the master.
+3. ***Open a Pull Request (PR)***: Once your changes are complete (or you want some feedback at an early stage of development) open a PR against the `main` branch. A PR initiates a discussion with the maintainer, which will review your code at this point. Furthermore, the [[CI/CD process|Continuous-Integration-and-Delivery]] will be kicked off and your code will be deployed to the dev-system.
+4. ***Discuss, review code and deployment***: Wait for feedback of the maintainer and check the deployment at the dev-system. In case of contributing a new driver the maintainer will also add the deployment-scripts in the scope of this PR. You may also be requested to make some changes to your code. Finally, the new changes should be safely incorporated to the `main` branch and the updated Universal Resolver is running smoothly in dev-environment.
+5. ***Merge to the `main` branch***: If all parties involved in the discussion are satisfied, the maintainer will merge the PR into the `main` branch and will close the PR itself. You are free to delete your branch as all changes have already been incorporated in the `main` branch.

docs/continuous-integration-and-delivery.md

@@ -14,14 +14,14 @@ After every code change the CI/CD pipeline builds all software packages/Docker c
 
 ## Building Blocks
 
-The CI/CD pipeline is constructed by using GitHub Actions. The workflow (workflow file https://github.com/philpotisk/universal-resolver/blob/master/.github/workflows/universal-resolver-ws.yml ) is run after every push to the master and on ever PR against master.
-The workflow consists of several steps. Each step is implemented as Docker container that performs the relevant actions. Currently, the two main steps are: 
+The CI/CD pipeline is constructed by using GitHub Actions. The workflows are run after every push to the `main` branch and on ever PR against the `main` branch.
+The workflows consist of several steps. Currently, the two main steps are:
 
-1. Building the resolver
-2. Deploying the resolver
+1. Building the resolver (workflow file https://github.com/decentralized-identity/universal-resolver/blob/main/.github/workflows/docker-build-and-deploy-image.yml)
+2. Deploying the resolver (workflow file https://github.com/decentralized-identity/universal-resolver/blob/main/.github/workflows/kubernetes-deploy-to-cluster.yml)
 
-The build-step uses this container https://github.com/philpotisk/github-action-docker-build-push, which generically builds a Docker image and pushes it to Docker Hub at https://hub.docker.com/u/universalresolver
-The second step takes the image and deploys it (create or update) to the configured Kubernetes cluster. The Docker container fulfilling this step can be found here: https://github.com/philpotisk/github-action-deploy-eks
+The first step builds a Docker image and pushes it to Docker Hub at https://hub.docker.com/u/universalresolver.
+The second step takes the image and deploys it (create or update) to the configured Kubernetes cluster.
 
 ## Steps of the CI/CD Workflow
 
@@ -41,4 +41,3 @@ The second step takes the image and deploys it (create or update) to the configu
 * Bundle new release for resolver.identity.foundation (only working drivers)
 * Render Smoke Test results as HTML-page and host it via gh-pages
 * Update documentation
-