Azure DevOps is not DevOps (yet)

At Made Tech, our company mission is “to improve software delivery in every organisation” and recently while using Azure DevOps, I’ve been feeling that currently, these two things are mutually exclusive.

Made Tech’s Guide to Continuous Delivery Tools

Since we wrote the original article just a little over two years ago, we’ve seen a fairly big shift away from self-hosted tools to feature rich Software as Service (SaaS). We’ve also seen nearly all Continuous Integration (CI) tools blur their lines with Continuous Delivery (CD) providing an all-in-one solution.

Dismantling Silos

A silo exists in an organisation when one group within the organisation has differing goals to another. In most organisations there are groups of people that, usually, have an objective to fulfil by an agreed upon date. For example, the Sales team is set a mandate to increase the number of customers of the company by 10% every month, whereas the Support team has internal performance goals, and one of them is to deliver support within a fixed budget.

Keeping code quality high

Code quality is a term that is often thrown around in the software engineering industry. And like the art of coding itself, it is very subjective and its true meaning will differ depending on an individual, or a team’s beliefs. But at its heart most engineers and teams would agree that good quality code is easy to read, well tested, and maintainable in the long term. But how do we achieve this?

Creating Environments That Promote Communication

In any organisation, one of the most powerful ways you can empower your team is to give them an environment that allows them to communicate freely at all levels. At Made Tech we actively encourage every member of the team to initiate or join any discussion that interests them, whether it be giving their opinion on how a part of the business runs, or introducing a new way of approaching how we work.

Trusting teams to deploy at any time

Developers should be allowed to deploy at any time. Many find this a scary prospect since it makes traditional release management and QA very hard. We have found that empowering developers to own the responsibility of deployment allows you to ship software much faster whilst maintaining or even improving the safety of releasing changes when compared to more traditional processes.