A Quick Summary of DevOps

What exactly is DevOps?

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support. (http://theagileadmin.com/what-is-devops/)

Like Agile, it's a rather large topic, but the main point of it is that developers work much more closely with Operations to ensure a more resilient release cycle. It's also characterised by Operations using many of the same techniques as developers - for example: source control, automation, and of course the Agile methodology.

 Adopted by all the big tech companies, DevOps allows for hyper-efficient deployments with much faster releases and far less production issues. In fact, the highest performers use DevOps to do 30x more deployments, 8000 times faster, 2x more successful, with 12x faster Mean Time To Repair than the worst performers (those who aren't using DevOps).

As a result, Amazon deploy to Production every 11.6 seconds. And they have very few Production issues. How? DevOps.

There's a lot to it, but some of the basic concepts that allow for this level of efficiency include the following.

Smaller Changes, Deployed More Frequently

Some of the biggest disasters in IT history have come from projects that had the longest lead times. Usually this is due to one reason: When they went live, it was the first time the code had ever been in a Production environment. To be good at DevOps and achieve a high level of fast, reliable releases, you need to get good at releases by doing more of them, more often. This involves shifting to a model of smaller changes, and more efficient releases.

Do Painful things More Frequently

There needs to be easier access to the painful process of releasing to Production. This is in contrast to traditional thinking that tends to treat releases as big scary things that everyone has to make a big deal over. Being efficient at DevOps involves streamlining and improving the release process in the same way we have streamlined our Development and Testing practices over the past few years.

Common Build Mechanisms

Rather than having distinctly different environments and setups for Development, Test, and Production, there needs to be a concerted effort to make all these environments as similar as possible.

Configuration as Code

To make it easier to implement Common Build Mechanisms, our deployment artifacts such as configuration, build scripts, automation scripts etc should be treated in the same way as code and managed under Source Control.

Automation

Like regression testing, deployments and environment setups should be as fully automated as possible, to allow for frequent and error-free repetition.

Definition of Done to include "Works in a Production Environment"

To take DevOps seriously, the ability to deploy to Production needs to be built into work processes.

Targeted Deployments

Techniques such as feature flags and deploying changes to small subsets of users can allow an organisation to get started with faster deployments.

High Trust, Peer Review over Approval

To adopt DevOps, we need to free ourselves of the learned behaviour that low trust, approval barriers and long lead times make our products more stable. The evidence is that they don't. Also, in studies, higher trust and lower lead times are seen as an indicator of both quality and happiness. While there might be some barriers to overcome up front, these changes overall make everyone more confident, more productive, and more efficient.

More interaction between Development and Operations

The underlying concept of DevOps is more interaction between Development and Operations. While before, we had a wall of procedures and artifacts between the two departments where work was thrown over, the goal now is to "knock that wall over and build a bridge". This means Operations getting more involved in the process earlier on to create common build mechanisms, configurations and automation. And it also means Developers being more involved in the release process.

Conclusion

Our job as developers is to release to Production without breaking anything. To get better at that, we need to do it more. A lot more.

Much the same as the adoption of automated testing, work needs to be done upfront to set up the infrastructure to allow DevOps to be safe and efficient. But like automation testing, these efforts pay huge, ongoing dividends.

DevOps is being used by most of the large tech companies and is allowing them to become extremely competitive by extensively reducing their lead times and quality issues. Those who refuse to adopt DevOps risk being left far, far behind.

*

There is a lot more to DevOps that I haven't mentioned here. Learn more with this course.
​http://www.microsoftvirtualacademy.com/training-courses/assessing-and-improving-your-devops-capabilities If you don't have much time, make sure you at least watch video 2.

Multitasking with My Work in Visual Studio

In Visual Studio 2012+ there is a button in the Team Explorer you may not use as often as you should. "My Work" contains 4 sections.

In Progress Work

This contains your current "context", what you're currently working on, your pending code changes.

Suspended Work

This is the most interesting feature, I think. It allows you to change the context which you are working in so you can switch tasks on request.

Imagine you're deep into coding a feature and an urgent bug is raised that demands immediate attention. Your code might not even compile yet but you have to drop it and get a working setup.

Simple. Just hit "Suspend" and your current changes will be suspended. But not just your changes. This doesn't just save the current state of the source code, it saves EVERYTHING, breakpoints, watches, open windows.

When the bug fix is complete and checked in, simply drag your suspended work back into the "In Progress" section.

This very short video explains the feature in more detail.

Available Work Items

A handy query that shows all the work items currently assigned to you. This includes bugs automatically raised when your changes have broken the build. It can be filtered by Iteration and has a handy link for creating new tasks.

Perhaps most usefully, dragging a task into the "In Progress" section changes its status, which is reflected on the team scrum board.

Code Reviews

Code reviews you have requested or received display here, and various filters can be applied. You are doing code reviews using Visual Studio, aren't you?

Conclusion

In short, the My Work window provides a handy at-a-glance look at your current work in progress, as well as offering the extremely useful Suspended work feature which allows you to quickly and easily take on urgent tasks without losing your context.

The breakpoint will not currently be hit. No symbols have been loaded for this document

Here are some ways to fix the notorious "The breakpoint will not currently be hit. No symbols have been loaded for this document" issue in Visual Studio. Many of the steps may not apply to your situation, but I've tried to make this a comprehensive list that you can check whenever you get this issue.

1. Get latest code from Source Control
2. Compile.
3. Run iisreset to reset IIS if you are using IIS.
4. Attach to the appropriate IIS instance (or all of them).
5. Add a breakpoint and run your application.

If you miss step 3, your breakpoint will not be hit, even though your assemblies has compiled and breakpoint is shown as active. You may need to run iisreset in an administrator command prompt to ensure you have the right permissions.

Some more ideas if the above doesn't work:

Check where your dll is being referenced from and ensure that is the code you're trying to debug.

Check you are in the correct mode when building: Debug/Release as they may put the dlls in different places.

Are you attached to the correct process?

For a website on IIS, is the code you're working on the same as the code running in IIS? 

Go to Debug > Windows > Modules and if the relevant dll is there, right click it and load symbols.
If it's not in the list, try running the code anyway. Sometimes even though it says the breakpoint will not be hit, it's only because the dll is not loaded until you enter a scenario that needs it. Try the scenario that depends on the dll, and it may just hit the breakpoint anyway.

Restart your browser. You might have something cached from an older dll.

* 

Do you have any other tricks to get around this issue? Leave a comment!