An Introduction to DevOps
At OCS we are involved with many large organisations. All of those organisations have now adopted some kind of Scrum or an Agile method of working. Our consultants are often a bridge between the developers and the operations team. Due to time pressures and often long release cycles, there can be some friction between these two teams, with both teams pointing the finger when something goes wrong – it's never nice to be in the middle! Which where DevOps comes in.
“A great team doesn’t mean that they had the smartest people. What made those teams great is that everyone trusted one another. It can be a powerful thing when that magic dynamic exists.”
The Phoenix Project, Gene Kim
DevOps is a methodology, which supports Agile development, for ensuring effective collaboration between the two teams – Dev (development) Ops (IT operations).
So what is DevOps? To quote the recent SAS blog - “DevOps is not rocket science” whats-with-all-the-fuss-about-devops.
DevOps tries to prioritise people over processes and processes over software tools. It tries to bring everyone together- developers, testers, operations, security, infrastructure. All teams being considered equally important to the process. The common goal being to delivery quality to internal/external customers.
There is no strict rule-set for DevOps, we do however see a number of common practices -
Continuous planning allows for starting smaller instead of creating one huge project plan. Start smaller by identifying the resources and outcomes needed to test the demand. This allows us to adapt continually, measure progress, learn from the customers' needs and very importantly shift direction as needed.
Collaborative development includes the process of continuous integration, This practice insists on frequent code integrations. Programmers should check in there work to the central repository. Ideally we should be performing an automatic build to check ensure the integrity of the build. Integrating application code frequently allows us to identify issues earlier in the life-cycle. This is beneficial since timely detected issues can be fixed easier.
With continuous testing we want to test as often as possible and ideally automatically. This will actually reduce the overall testing time since early feedback early in the life-cycle will help developers increase overal quality. Since the tests will be on a smaller scale, we can reduce the need for large rigid dedicated testing environments.
Continuous release and deployment
The goal here is to increase the number of releases. The progress being made is then evident for all team members and customers. This progress is shared equally across the whole pipeline, ensuring that all systems are in place for the final major release. Automation of this release process is key.
Continuous monitoring provides feedback to development teams regarding a product long before it is deployed to production. Since this monitoring is transparent this increases the confidence in the final product. The early feedback provided by continuous monitoring is critical for steering projects in the right direction. At this stage we also start getting valuable information of performance metrics.
Continuous feedback and optimisation
Continuous feedback from customers is vital to quickly understand any issues being experienced. The root cause of any issues should be visible. This information is vital in detecting any unintentional deviation from the customer expectation.
Benefits of DevOps
DevOps helps the collaboration of developers and operations team members ensuring high quality for customers.
SAS and DevOps
SAS has added GIT integration into a number of SAS applications – SAS Studio, Enterprise Guide and SAS DI Studio as well as providing a set of datastep functions for GIT integration. See this link for more information -
Another very interesting tool is SASUNIT. This is a suit of macros allowing for Unit testing of SAS code and fits into the DevOps methodology by allowing continuous testing and test driven development of SAS code. By defining ‘expected’ vs ‘actual’ results a comparison can be made to ensure any changes to code still result in the same output. See this link for more information on SASUNIT
OCS and DevOps
We at OCS have been steadily gaining experience in helping our customers adapt to the DevOps methodology and utilising the SAS and the many non-SAS opensource tools needed for the DevOps pipeline. We are now seeing the benefits, reduced development time and increased quality, DevOps is bringing to our customer projects. Our advice –
- Start small and focus first on the principles of DevOps. Perhaps select a small project or team to begin with. Initially implement one or two of the principles, for example begin with continuous testing.
- Create goals and continually measure against these goals in order to demonstrate the improvement.
- Transparency is key, make any progress transparent both inside and outside of the team. This will build momentum.
If we can help in anyway with SAS and DevOps then please contact us.