Hi All,
i want to ask how can i start DevOps.
I am currently Working as System Engineer(Windows Server, Exchange Server, system Center, Lync Server VMware etc.) may i know how can i advance my career as DevOps.
I would start by reading information about the concepts on various web sites to understand the main pillars. it requires a shift in how some think about development of computer systems.
There are several pillars DevOps is based on, not all systems or companies or people apply them all but if you understand them you’ll be on a good way forward and benefit from them.
Things like:
Self-Service Configuration
Continuous Build
Incremental Testing
Continuous Integration
Continuous Delivery
Automated Release Management
Automated Provisioning
Usually you’ll find some of those already implemented and some not, for various reasons. Either lack of people, lack of time, company decisions on where to put the focus and more.
Understand that the terms used do not imply a certain tool. There are various tools in the market to address each aspect of the pipeline, Some free, some aren’t, some will address most of the points above in one product, for example Team Foundation Server (TFS), some will be specific to one task and require you to combine multiple tools to achieve full pipeline.
On a personal level, its about you trying to adopt methods mostly used by software developers. Things like:
-
Automate activites by any programming language your comfortable with, lets say Powershell
-
Any script you ever write, store it in a Source Control program, lets say TFS. Choose an editing program that supports builtin connection to a Source Control, lets say Visual Studio
-
Learn about Unit Testing frameworks, those will sometimes be general ones and sometimes specific to the programming language you choose, for our example lets say Pester. Adopting a bigger testing platform might be more beneficial if you have several teams of programmers using different languages,things like TFS Test.
-
Create a Build system that takes the Code you entered in your source control, runs the Unit tests you’ve written and creates an output (an Artifact). In our example it will be TFS Build where the artifacst is our powershell script.
-
Use a Deploy / Release that allows you to send the artifacts you created to their proper destination. For our example Release Management that comes bundeled inside TFS. But for that matter it could be your own designed “Copy-this-to-there” powershell scripts.
-
Use the same artifacts and same methods for deploying to each of your environments - Dev, QA, Prod thus creating a workflow and order and integrating it with any exsiting incident/requirement systemns you already use in your organization.
-
Use a Configuration Manager tool to help provision hardware as automatically and efficiently as possible to make the entire pipeline smooth and fast, to minimize the wait time at each stage. In our example technologies like Powershell DSC
You can pick one of pillars and focus it deeper based on your needs.
You can choose to discard some of them when they do not fit your company/organization
or when focus requires extensive work.
You can swap the tools I addressed with various other tools and that’s ok. DevOps is not about the tools at the base level, its about mindset, about adopting methodologies of work to make the entire pipeline better, more reslillient, more testable and thus lower the pain of failed procedures or failed systems.
During your learning, as you work with Microsoft technologies I would use Microsoft Virtual Academy to learn how and what tools are used in the Microsoft environment, Videos from Jason Helmick, and Don Jones. But I wouldn’t stop there.
In my view in todays changing IT, you need to broaden your knowledge and understanding into non-Microsoft realms as well. With “Everything-in-the-cloud” shift, youre most likely going to have to, at some point, handle non-Microsoft technologies. Understanding the pillars and how a pipeline is constructed and created and following basic guidelines means youll be ready to use the same DevOps techniques in what ever changing environment youll face.
And since this is now way too long for some people to read 
ill stop here 
That was a great answer Arie … would make for a good blog post as well
@Christian: Sometimes all you need is a kick in the butt to start blogging. Its coming
Cant promise it will be in Danish, as I dont speak the language yet (that’s coming too)
@Ali: As this was written quite early in the morning I did miss two things
-
Measurement - What ever tool you choose, use logging, use timers, measure things.
If a certain tasks takes you 1 day, and you automate it and now it takes half a day. If you measure it continuously you get two main products from it:-
You find bugs faster, if you run an automated tasks 1000 times repeatedly and you’re used to it taking 1 hour and all of the sudden it takes 2…somethings wrong…and you just got another way to “Actively” find it and not be reactive as in waiting for a user to open a support ticket that something is down. It means you go back to your automation and check and recheck and employ more testing to cover some anomalies. This continuous improvements will make your work more agile and flowing.
-
Data to show executives - At the bottom line, our employers are interested in numbers. One task taken from one hour to half an hour isn’t much but if you do that task 1000 times a month there’s some cost reduction involved. They can see the ROI of putting a dedicated professional team to automate and save money. It is then that your expertise come into play by knowing how to create and setup the pipeline. It is then that you become an even bigger asset to your company. (Dont expect an immediate raise, but who knows
)
-
-
As I owe it to Don and the rest - Community. When you start working with the mindset of DevOps and start using tools you find are better. Find the time to contribute back to the community.
- Write a blog describing your learning process and implementation process.
- Go to conventions to learn and enrich your understanding and who knows you might actually give the talks and not just listen to them
- Contribute to the Tools you choose, be it stories about how you handled things, or actively developing tools. Don said it very well in past videos: Try to be the tool maker and not just the tool user.
- Join a local DevOps / Powershell / Other groups of IT people in your area.
- Enjoy the learning process and help others learn it too
All this will make you a more professional person and above all would make your employer understand how valuable you are to him.
From a personal point, I can only say about my self that getting into all this, has made me a better IT person, a better Ops person, a better Dev person.
That’s a wrap for now
Thanks Arie for your Valuable time. really helpful
Once Again Thanks.
@Arie: Looking forward to your future blog posts (I still need that kick myself). Are you based in Denmark?
I will be in a one years time if all works well
I thought this PDF from Puppet did a good job of giving a birds eye view of DevOps.
Get Started with DevOps: A Guide for IT Managers