GitOps keeps focus on apps, not on infrastructure

Development teams spend time on a lot of things other than their product. They manage infrastructure, DevOps and integrations, and even create staging servers so that an external agency can test out your sweet new redesign. Maybe it’s not even just one site to worry about, but a whole fleet of applications that need to be kept in-sync, secure, and up-to-date, all while sticking to a release schedule. No one has that much attention or experience to manage it all, and it’s a lot to ask of them to keep up with. In this demo you’ll get a view of how the same team solves these problems when their project is hosted on Platform.sh. In short, they don’t need to think much about them. The project didn’t move anywhere – it’s in the same GitHub repository the team is used to working with – but now it’s got some new tools and assurances that weren’t there before with only a few short files needed to configure it all. We’ll cover: Infrastructure-as-code: committed and clear infrastructure for all collaborators, where new services and upgrades are single character commits. Workflow: pull requests become live environments as soon as they’re opened, even for upgrades to infrastructure. Production data: a staging server for every proposed change, that’s not just a clone of production code, but also infrastructure and production data that the application really needs to have available for reliable testing prior to merges. Access: collaborators can test on isolated copies of production as easily as branching. One or many: control extends from a single application to a full fleet just the same.