GitOps is a set of guiding principles that work together to create a developer-centric Continuous Deployment setup. By using Git to manage infrastructure provisioning, configurations and deployment automation, the GitOps approach aims to provide a single source of truth as code. Thereby developers can continuously deploy code changes and requisition infrastructure without these requests getting stuck in a ticket queue in the operations team.  GitOps works on five core principles: 1. Declarative. Instead of using imperative, ad-hoc scripts, operators tell the system what they expect to see as the end result, and GitOps formulates this behind the scenes. Instead of telling it how to get there, operators define the state they want to see.  2. Versioned and immutable. By storing the desired state using version control tools, operators can retain a complete version history for each state and deployment.  3. Deployed automatically. Instead of pushing manual changes, the system automatically pulls changes from the Git repository and deploys them straight to the desired location.  4. Continuously reconciled. The system keeps all environments in the same state continuously until the Git repository is changed.  5. Operated in a closed loop. The system and state work communicate bidirectionally, allowing any changes made to the source to be pushed to the system, and vice versa. While GitOps isn’t always applicable for every situation, there are significant benefits to using GitOps principles, such as: • Full history and auditing. By using Git, operators can see exactly who pushed what, when, where, and how. So, if there’s a problem further down the line, operators know exactly who they need to talk to, or what they need to inspect.  • Simple deployment and rollbacks. Because system states will pull changes from Git automatically, it’s easy to deploy changes to different environments. And, if anything goes wrong, operators can quickly roll everything back to its pre-deployment state. • Avoids configuration drift. When operators push changes manually, it’s easy to end up with push changes that fail in some environments but not others. In Git, it’s easy to see if two systems are different before changes are deployed. • Detect manual changes. If someone does push a manual change, GitOps will detect and log this so operators can either roll the system back or push the change to a Git repository. When developers start working with multi-environment configurations, GitOps can make this unnecessarily complicated. Similarly, GitOps often struggles in complex enterprise setups where confidential information like database passwords need to be managed outside of a business CD setup. That’s not to say that GitOps can’t be adapted to work in these situations, but rather that there are other approaches that may be more suited to large enterprises.  An Internal Developer Platform, or IDP, is a self-service layer that allows developers to spin up new environments and deploy code changes on their own. Instead of requiring ops to clone databases, or needing developers to sift through YAML files or documentation to figure out how to push code changes, an IDP empowers developers to self-serve environments, deployments, databases, logs and anything else they need to run their applications. .  IDPs like Humanitec confer a ton of benefits to the DevOps ecosystem, like: • Easy infrastructure provision: When used in tandem with infrastructure as code (IaC), IDPs make it simple for developers to create databases or test environments without needing to requisition them from ops.  • Reduces operations load: Similarly, operations aren’t overloaded with menial tickets asking for new databases or environments, allowing them breathing space to get on with more vital tasks.  • Supports a continuous delivery system: By giving devs the power to run their own deployments and push them when they’re ready, it becomes easier to maintain an efficient delivery system.

Original article: https://humanitec.com/blog/gitops-vs-internal-developer-platforms