Current typical tools such as Jenkins need the deployment environment credentials to deploy the application, so when the pipeline agent is hacked, the deployment environment will also be compromised. This master’s thesis evaluated the GitOps approach as a continuous deployment approach without needing deployment environment credentials to address security concerns. Kubernetes (K8s) is the most common container organizer that allows users to manage application configuration using a declarative approach. It makes sense to put these files in a Git repository. In summary, GitOps embraces many of the Development and Operations (DevOps) philosophy’s excellent practices, such as Continuous Integraion/Continuous Deployment (CI/CD) pipelines and Infrastructure as Code (IaC). It introduces a new concept: the Git repository as a single source of truth. It is a developer-centric approach since developers are familiar with Git, and it is helpful to leverage this paradigm to offer developers more autonomy in managing infrastructure. In GitOps, two kinds of repositories are differentiated: the application repository and the deployment repository. The application repository contains the application’s source code, while the deployment repository contains all deployment manifests of the currently desired infrastructure of the application. The deployment repository is considered the single source of truth. There are two ways to implement the deployment strategy for GitOps: push-based and pull-based. The push-based deployment is similar to typical CI/CD pipeline tools like Jenkins or GitLab CI/CD. On the contrary, the pull-based deployment approach uses a dedicated continuous delivery tool, called Operator, placed in a K8s environment and controls the execution of the deployment pipeline by continuously comparing the desired state defined in the deployment repository with the actual state deployed in the K8s cluster. The pull-based model was chosen for implementation because there is no need to expose K8s credentials to external services like the deployment pipeline. Three well-known problems of this model, which are: modeling multi-environment configurations, promoting releases in these environments, and secrets management based on GitOps principles, were evaluated and investigated. In addition, the DevOps team topology was considered an essential factor in the presented solutions and their evaluation to increase the acceptance of GitOps by the development team. To model multi-environment configurations, multi-branch and single-branch strategies were investigated, and according to their advantages and disadvantages, single-branch (environment per folder) strategy was considered for implementation. In order to more efficiently promote releases or other configurations among environments, the configuration were divided into four general categories, which are: application version, K8s settings, static business settings, and non-static business settings. Kustomize was used as a K8s native configuration management tool, and GitHub workflows were written for the automatic update and promotion of the application version between environments, which required manual approval for environments with higher sensitivity, such as the production environment. Since some of these settings will change in every new release, or new settings were added that had to be specified by the development team, and due to their lack of access to the deployment repository, a method was implemented to put these settings in the application repository. Along with the application source code, they were maintained by the development team, and their changes were replicated in the deployment repository, thus increasing the acceptance of GitOps in the development team. As a result, by limiting the access to the deployment repository to specific people and also providing the possibility that part of the settings can be maintained directly by the development team, besides maintaining the principle of the single source of truth, the security and acceptance of GitOps will increase. Another well-known problem with GitOps is secret management. Secrets in K8s and GitOps were explained and investigated. The most crucial reason why secrets cannot be stored in Git is that secrets are stored in Git as plain text. In the following, the advantages and disadvantages of secret management strategies in GitOps were introduced and compared. Based on the GitOps principle that everything should be defined in Git, the strategy of encrypting secrets in Git was chosen and implemented. In this strategy, the secrets are stored encrypted in Git along with other files, and after being deployed in the K8s cluster, they are decrypted via SealedSecret controller and can be used by the application running in the cluster.