This quick video provides an overview of the 6 categories in a devops environment - the 6 C's. To have an enterprise-grade devops workflow, you must have these 6 categories taken care of. See below for details:
This is all about how your team communicates. This is where you make work visible, which is a principle of The First Way of devops, which is Flow. All work needs to be tracked in the same system, and all communication must be in the same place. It's important to consolidate any silos and make sure there are not multiple places to see work or communication. VSTS does a great job of consolidating all of this. And coupled with Microsoft Teams or Slack, your team can keep everything together.
This means code, server config, docs, and every artifact needed to compile, test, run, deploy and operate your software. With modern tooling and package managers, it can be tempting to keep some parts of your software or dependencies in a separate place, and that might work for a time, but this rule is time-tested. The most risk-averse way to ensure you can always build any version of your software is to store everything required for that version in one repository.
Because of the movement in 2005, this part of devops is well-known, having come from Extreme Programming. But sometimes version stamping and release candidate packaging are left out. Don't forget those two techniques.
While unit tests and component tests have a good home in the continuous integration build, we must continually test all aspects of the software. In the first-line test environment, we'll want to run a complete acceptance testing suite. In some cases, we'll want an integrated test suite to ensure the system works well talking to other systems. And then we need tests for non-functional requirements like scaling, auto-failover, capacity, and making sure transactions don't drop while a zero-downtime deployment is happening.
This is the practice of arranging environments in a sequence and deploying to the next environment once a release candidate can passed the validations running in the previously deployed environment. The environment at the end of the line is the production environment, which is often protected by an auditable approval process once a release candidate version is cleared for deployment to production.
Our software has no value unless users are using it. We want to keep a watchful eye on the software because if we see a dip in usage on a given day, it could be because of a problem that has cropped up that isn't triggering any other alarms or throwing errors. In a devops workflow, every person is an engineer (problem solver). There are no more devs and ops. You run what you wrote, just like how it was a few short decades ago. So we want to keep a watchful eye on how our system is performing by shipping all the logs to a centralized location out of the production datacenter. This enables people who are not productione environment sysadmins to analyze the logs.
This barely scratches the surface. There is much more in every category. I hope the video is useful to you. Subscribe to the channel for more devops videos.