DevOps is a natural progression from implementing good ALM. Building upon its ALM experience, SSW has developed expertise around implementing DevOps into a product's lifecycle.

DevOps enables your organization be more agile and helps bring a consistency that improves quality and allows you to be responsive to changes and issues. It is about integrating your Development team and Live Operations team with a combination of supporting tools and an embedded culture of working together and improving.

SSW helped Microsoft demonstrate the future of DevOps at Microsoft Ignite Beijing, which you can read about here. SSW chief architect Adam Cogan did a DevOps session at Microsoft Ignite Australia.


  • Increase collaboration between the development and operations teams
  • Reduce your delivery cycle time
  • A defined and implemented standard that covers the quality & delivery that is expected
  • Reduce your technical debt
  • Increase developer efficiency


Although the DevOps movement is only a few years old, it is already mature and widespread. 'DevOps' is a portmanteau word that brings together 'Developers' and 'Operations', with the main goal being to bridge the gap that exists between 'Dev' and 'Ops' in order to build trust and have the teams work better together.

To achieve this, DevOps seeks to ensure that all teams involved in the software development line - from developers to testers to employees in user experience, product and operations - are collaborating and communicating effectively through all stages of development. This in turn reduces the amount of rework that needs to be done by each team and streamlines the development process by constantly improving it. As a result, businesses are able to respond to market feedback more quickly and provide faster and higher quality continuous delivery to the customer.

Here are some highlights in the short and eventful history of DevOps at SSW:

2005 - SSW moved to Microsoft Visual Studio 2005 Team foundation Server
2008 - Microsoft adopted Scrum, and SSW followed shortly thereafter - SSW now has 9 Scrum Masters, and use the framework in all aspects of business
2010 - SSW updated its practices to get devs & testers working together
2013 - SSW adopted the latest deployment tools, such as Octopus Deploy
2014 - Application monitoring tools started becoming mainstream, such as App Insights and New Relic
2015 - Release Manager becomes an SSW development staple

DevOps culture

DevOps is more than just technology, it is a culture. The entire organization needs to buy in to get the most out of it.

The goal is to get the product teams working with Developers, who are in turn working with Operations, who are working with testers and providing feedback.

DevOps requires a cultural shift. There are 3 important points:

1. The primary characteristic of DevOps culture is an increased collaboration between the roles of development and operations. All the roles across the organization (dev, ops, test, etc.) should work in unison to create great working software, rather than squabble over whose responsibility it is that there was an issue in production.
2. Everything should be automated and repeatable ¨C from building, testing, deployment, etc.
3. Everything should be Agile.

The framework of enterprise DevOps

An important initial step is to select which components will make up your DevOps framework. The components you select will depend on the type of product you are building, and the level of monitoring and feedback you require, as well as your team¡¯s capabilities. Another impacting decision will be if you require all tools to be deployed on premises, or if you will take advantage of the cloud.

DevOps cycle
Figure: DevOps cycle

Building and refining your DevOps framework is an iterative process. Defining and installing the tools is just the beginning. It is just as important to customize and tweak it for your environment to get the most out of it. e.g. Custom deployment scripts or UI tests.

The lifecycle of an SSW development task with DevOps

Here is the lifecycle of a typical bug at SSW:

a) A bug is found
b) In the monitor tools, the bug is confirmed and reported to development team (TFS). A bug is created in the product backlog automatically by the monitoring tool.
c) A developer updates the bug, sets effort, and drags it into backlog.
d) Work Breakdown Structure (WBS) - break the bug down into subtasks.
e) Assign to a developer for the next sprint.
f) Investigate the bug.
g) Create a new unit test to capture the bug and show that it fails. This prevents this bug from happening again in production.
h) Fix the bug.
i) Associate the work items to the changeset.
j) Check-in the code with comments.
k) The automated build server will then kick off the CI build.
l) Check that the unit test covering the new bug passes.
m) Check SonarQube to ensure we have not introduced new technical debt.
n) Open the release management tool and promote the build from the development environment to the QC/test environment.
o) Selenium test are automatically run.
p) Load testing is done automatically.
q) Once the bug is confirmed fixed in the test environment and there was no test regression, then the build is promoted to production.
r) The monitoring tools are checked the following day to ensure that the bug no longer shows up after the deployment.

What stats does SSW track in DevOps?

Before we make any changes, we make sure that we start measuring. This way we can see what areas have room for improvement. Later, we work with you to improve this numbers through DevOps automation.

The table below shows some of the metrics SSW tracks:

Prepare list Benefits
Deployments per sprints Deploying more frequently allows for faster feedback.
Number of unhandled exceptions Unhandled exceptions can typically go unnoticed. Using a monitoring tool can help detect these and bring the number down, improving the customer experience.
Unit Test Coverage A higher test coverage gives confidence that there aren't regressions with new releases.
Automated UI Test Coverage Automated UI testing can go over the typical use cases in the UI, giving confidence that there aren't regressions with new releases.
Number of story points per sprint (velocity) With the reduced overhead from DevOps automation, developers can spend more time coding.
Number of DevOps issues per sprint DevOps issues are things that impact production uptime or accessibility. Learning from each DevOps issue and putting safeguards in place to reduce the number of issues next sprint is great for the end users.

One day DevOps lightning overview

If you have questions about DevOps or don't know how to get started, join in our one day DevOps presentation and training.

Our experts will introduce the topology of DevOps, run through a cycle of DevOps as we use it, and make you confident to run DevOps yourself. You will be amazed at how DevOps can streamline your software delivery.

Let us help you integrate DevOps into your organization's culture

DevOps is more than just technology, it is a culture. We can come in and work with your company to build up your capabilities. We will work together, analysis your application, help you choose the right functions and tools, and help you save time and money.

Our mission is to help you thrill your clients with the ease of delivery you will provide.

Australia Wide

We have consultants available in all Australian capital cities including Sydney, Melbourne, Brisbane, Adelaide, Perth and Canberra.

Get your project started!

Maximium 2000 characters.