Developer Viewpoint — How has DevOps changed how we work
“The most powerful tool we have as developers is automation.” — Scott Hanselman
Developer Viewpoint is regular section on the blog a section that involves two developers discussing an issue. The discussion takes the shape of a dialogue and in this issue, Ekhor Asemota discuss DevOps with Mark Hartshorn.
Ekhor is an experienced Microsoft developer with experience in DevOps processes for Dynamics 365.
Mark is a highly experienced software engineering who has worked in several industries using a broad range of technologies such as C#, ASP.NET, SQL, SSIS, SSRS, SSAS, BizTalk and PowerShell. He currently focuses is on .NET, Azure, PowerShell and DevOps.
Ekhor: DevOps is the current buzz in the industry and sometimes one is tempted to say it is the regular hype concepts that appear in the industry quite often. What is your take on this?
Mark: DevOps has existed in different forms for a long time. Prior to DevOps, Microsoft’s nearest buzz words would have been ‘Application Lifecycle Management (ALM)’ which looked at how a system was created from requirements through to deployment and eventual retirement, although in my own experience it was only every used from initial requirements through development and deploying the system(s) into the development/test environments (Dev and SIT etc). Once the development testing was complete the system would be packaged and handed to the operations team for deployment to the controlled environments further up the chain (UAT, OAT and Production etc.).
The majority of this was developed using various waterfall methods and required project plans for systems which were measured in years. This changed when Agile/Scrum development was introduced although the release aspect for larger projects was still operating in a waterfall method.
This started to change for Microsoft development teams in 2012 when Microsoft purchased a third-party system called ‘Release Manager’. This could be integrated with Team Foundation Server (2012). This finally allowed code to be ‘Built Once/Released Many’. ‘Release Manager’ was then integrated with Visual Studio Team Services (VSTS now, Azure DevOps) and is now a fully integral part of Azure DevOps Pipelines.
Going back to your original question, I think the biggest change which has occurred with DevOps, and not just in the Microsoft world, is the ‘Built Once/Release Many’ concept, this has allowed a major increase in a system release cadence. We used to plan a release x number of months away whereas now we should be planning to release changes through the various environments and to production at the end of each sprint!
Ekhor: Following up on the previous question, how would you describe DevOps to the uninitiated?
Mark: DevOps is often described as the automation of development, but this is only a third of what DevOps is. The other two third, deals with the ‘People’ and ‘Processes’ within the organisation. Without changes in these areas’, teams will still be restricted in their working practices and it will be very doubtful that the organisation will obtain any benefit from DevOps.
An example of this can be shown by looking at the ‘traditional’ objectives of the Development and Operations team in most large organisations:
The measures of either team are the opposite of the other. What chance does the development team have of increasing the number of deployments to production if the operations team are told that their job is ensure the system is always available/stable? Looking at it from the operations team’s point of view, how can they ensure stability? if they are told to allow the development teams to release to production on a more frequent basis?
This isn’t a problem for either the development team or operations team. You just can’t say to the two teams you need to work together and hope for the best. This becomes an overall cultural issue which needs to be addressed in the whole organisation at every level for it to work successfully.
So, for me DevOps is made up of the following three items
- Automation
- People
- Process
And it requires all three for it to work successfully.
Ekhor: What would you say are the keys benefits of DevOps for the modern-day IT industry?
Mark: The increase in the release cadence allows organisations to create/change/fix systems quickly and respond to the changing market place. This speed increase also gives feedback to the organisation of what functionality works well. This allows them to be more adaptable in the short term which can provide an advantage in a competitive market.
Ekhor: Azure DevOps is currently one of the current major DevOps offerings. Are there any features of this platform that you think makes it easier to adopt DevOps?
Mark: To me the main advantage of Azure DevOps is that is a fully integrated service which allows you to perform all the major activities in one service rather than having a number of different tools/services. This means everything is in one place and has the same look and feel across the different areas. To be fair I am probably biased as I have worked with the Microsoft Azure DevOps tool set in its various incarnations starting with Team Foundation Server 2008 back in January 2009.
Ekhor: As no software solution is perfect, which features of Azure DevOps, would you say, needs improvements?
Mark: For me the ‘Test Plan’ side of Azure DevOps is the one area where I would like to see more functionality. In 2010 Microsoft released a product called ‘Test Manager’ (part of Visual Studio 2010) which had the ability to write/record tests and allow them to be replayed. Unfortunately, they didn’t take the product forward and from 2016 onwards, Microsoft started recommending Selenium for web testing etc. The one area I did think was useful was the load testing which allowed you to run tests from different Microsoft data centres around the world. Alas it has been announced that this is being removed from both Azure DevOps and Visual Studio in the future.
Ekhor: As Azure DevOps is designed for a very broad audience, it is expected that enterprises which select this platform will often have to make some customizations to the platform in order to address their specific needs. Could you share with us some customizations which you have worked on?
Mark: The two areas were organisations tend to customize Azure Devops are:
1. Work Items
2. Pipelines
Work items provide you with the ability to record your processes i.e. When you create a new project, you have the option to select from the following options:
- Agile
- Basic
- CMMI
- Scrum
Each of these gives you a different set of processes which can be followed by a Azure DevOps project. The basic option provides limited processes whereas the CMMI process follow the CMMI standards closely. Scrum and Agile options fit in between. This may seem restrictive at first, but the recommendation is for an organisation to choose the option closest to their current operating model and then customize it as they work with it i.e. Make small changes each sprint.
Pipelines deal with the building and releasing of code i.e. Continuous Integration and Continuous Delivery. This is a very extensive area which can integrate with other third-party tools i.e external source code repositories, GitHub, BitBucket etc, build tools like Jenkins, Mavern etc. It is also easy to use scripting languages like PowerShell to expand on its capability. If you require more specific extension’s, then you can create your own and upload them to the Microsoft Gallery. These can be restricted to your own Azure DevOps organisations or even useable by the public within the Gallery’s market place
Myself I have been involved on projects where the chosen work item template has been heavily customized over numerous sprints and once complete didn’t have any resemblance to the original template.
Within pipelines I have been involved in creating numerous extensions to customise build and release processes for various systems. Recently most of my work has related to Dynamics 365 and have been written in PowerShell and then published as a private extension in the Gallery. One of my favourite extensions just updates a wiki page within a project and it displays the different environments for the system and the versions of the CRM solutions within each environment. Very useful to see at a glance what is installed where.
Ekhor: What would be your recommendations to a typical .NET software engineer who wants to be relevant in this new DevOps world? Are his or her existing .NET/C# skills still relevant or it is time to switch to PowerShell?
Mark: With Azure and Azure DevOps I find I can do most things in PowerShell, that doesn’t mean .NET/C# is not relevant it just means my preference is to work with PowerShell. You can achieve almost the same in C# and there is very good documentation showing examples for both C# and PowerShell, but if needed to figure out how an API call to Azure DevOps works I prefer the responsiveness and small foot print of the PowerShell ISE compared to Visual Studio.
Ekhor: While on PowerShell, I am aware that you developed a very flexible release pipeline for Azure DevOps with nothing but PowerShell. Would you be able to give an overview of this solution?
Mark: On a previous project the team I was working in had an ‘opportunity’ to try and produce a release plan for multiple releases over 18 months. This included multiple functional areas and the understanding that the release order was fluid. It could change multiple times within a day when the various business leaders were involved. Based upon this the single code repository was split into functional areas with additional core code being in their own repositories. At the end we had over 14 repositories (deploy-able units) which needed to have their own CI/CD processes and a build and release process for when the code was ready to be deployed to the controlled environments. In simple terms the release process allowed us to automatically:
1. Create a release branch for each repository identified in the release
2. Create a new CI build and new pull request (PR) build for the new branch
3. Link the new branch and PR build to ensure quality if the release code needed to be changed
4. Create a new release pipeline bringing together all new artifacts created by the new (CI) builds
To identify which repositories were included in a release you just need to tag the code at the relevant commit. The process was made reusable as you link it to existing ‘build’ and ‘release’ templates which it uses to create the new builds and release. If anyone is interested in a more detailed explanation, then I am happy to provide additional information on the process.
Ekhor: Do you know if this release solution you developed will be released to the wider community through our Capgemini Microsoft’s Team Open-source initiatives on GitHub?
Mark: Eventually Yes, but at present there are other opensource initiatives which have a higher priority. It will also take some time to extend existing documentation before it could be made public.
Ekhor: I am sure our audience would be interested to explore some of the areas which we have highlighted today especially in terms of personal development plans. What would be your recommendations to them for DevOps and PowerShell?
Mark: For a greater understanding of DevOps I would recommend reading ‘The Phoenix Project’ book I read it over 4 years ago and as it focuses on the People and Process side it is still very relevant today. If reading isn’t your thing (how are you in IT today???) then Microsoft run a two day ‘People and Process’ workshop which provides a good overview.
For PowerShell its like any language you need to be able to be use it on a regular basis, but you also need to understand what environment you are working with i.e. trying to configure Azure Services with PowerShell is going to be difficult if its your first exposure to both PowerShell and Azure. Microsoft do provide good documentation on PowerShell but I have to admit I was lucky to attend a 5 day course on ‘Automating Administration with Windows PowerShell’ (10961B). The first few chapters in the course, which lasted over a day! just showed you how to use the PowerShell help system. This has probably been the most useful information I have learnt so far.
Read other stories from the Capgemini Microsoft Team.
