What exactly is devops?
- Thread starter Alvin
- Start date
Its basically the marriage between software development, infrastructure engineering, and software operation.
But that's a very vague answer.
The first thing you need to understand is SDLC (Software Development Life Cycle)
(writing next post, sec)
But that's a very vague answer.
The first thing you need to understand is SDLC (Software Development Life Cycle)
(writing next post, sec)
I hear about agile a lot, a lot of the dev teams use it so they can push out software rollouts and updates faster.
NYSTATEOFMIND
Superstar
it has alot to do with automation to help push the rollouts faster- if your an infrastructure engineer whose firm is adopting AWS, best to start learning about container tools like Docker, Mesos etc
So lets say you and 5 friends want to build a web app.
Before you worry about what language, what platform, etc etc, the first thing you need to thing about is SDLC.
I'm going to be very basic here.
You need to decide on your process. How will you go about this? Will each user work on code and submit work? Who will be in charge of submissions? Will a master branch always be in production? Will you have a dedicated isolated Dev enviroment?
To answer all of these, you need to come up with a means of colloboration and Version Control.
You can use many things for this, but on the enterprise level many companies use VSTS/TFS (they are the same, but one is cloud and one is on-prem)
Once you decide that, you need to come up with what's called a branching strategy.
This is a slide from a presentation I gave to a client last month (pls dont steal)
Don't let this confuse you, its much simplier than it looks.
So this is a 3 Branch Dynamic Strategy.
Branch 1: Master Branch. This is the code that is in production running on your production environment. You NEVER make direct alterations to this ever (aside from hotfixes). This is the gold standard. That is why i put a lock symbol by it
Branch 2. Develop Branch. I know its below Release, but that's for a reason. Develop Branch (or Dev) is where your developers do the actual work. They pull the current repo down from master before assigning tasks to themselves. Tasks (or often called "tickets" or "User Stories") are what you actual develop. You see those numbers? 1276, 1279? Those represent ticket numbers.
Let me explain, say i'm a developer and we get a request to change the banner on our website from green to blue. If Dev has already been hydrated from master, I pull from Dev into my own little off branch (which I name after the ticket to avoid confusion) and begin work. Once I am finished with this change we go the next step....
Before you worry about what language, what platform, etc etc, the first thing you need to thing about is SDLC.
I'm going to be very basic here.
You need to decide on your process. How will you go about this? Will each user work on code and submit work? Who will be in charge of submissions? Will a master branch always be in production? Will you have a dedicated isolated Dev enviroment?
To answer all of these, you need to come up with a means of colloboration and Version Control.
You can use many things for this, but on the enterprise level many companies use VSTS/TFS (they are the same, but one is cloud and one is on-prem)
Once you decide that, you need to come up with what's called a branching strategy.
This is a slide from a presentation I gave to a client last month (pls dont steal)
Don't let this confuse you, its much simplier than it looks.
So this is a 3 Branch Dynamic Strategy.
Branch 1: Master Branch. This is the code that is in production running on your production environment. You NEVER make direct alterations to this ever (aside from hotfixes). This is the gold standard. That is why i put a lock symbol by it
Branch 2. Develop Branch. I know its below Release, but that's for a reason. Develop Branch (or Dev) is where your developers do the actual work. They pull the current repo down from master before assigning tasks to themselves. Tasks (or often called "tickets" or "User Stories") are what you actual develop. You see those numbers? 1276, 1279? Those represent ticket numbers.
Let me explain, say i'm a developer and we get a request to change the banner on our website from green to blue. If Dev has already been hydrated from master, I pull from Dev into my own little off branch (which I name after the ticket to avoid confusion) and begin work. Once I am finished with this change we go the next step....
Last edited:
PULL REQUESTS AND COMMITS
I seperated this into its own post because I can't talk about pull request without talking more about process, access, rights, groups.
So you and your 5 friends are all developers, but you don't all have equal rights. You can't, things wont function that way.
One of you has to be the Project/Build Administrator.
So lets back up so we know why this is important.
Lets say I'm one of your developers right?
I hit you up and say "Hey i'm done with this change, i'm going to go put it into the master branch ok? Cool"
But i'm actually an idiot and my change ends up breaking the entire production environment.
This is where rights come into play. Most master branches are locked so that they can never be changed. But if the master branch is locked... how will my fixes ever see the light of day?
Well that's why I make a pull request. I submit my code as complete to you, the build admin, and you decide whether or not it meets the standards.
And if you say
"Ok looks good" You promote it into Branch 3: The Release Branch.
Now as I said earlier, this is very very basic, because in a real company you would promote this to QA (SIT,UAT) before going to release.
So my code is in Release, but what does that mean? How can we be sure it wont break? its not on production so how what does any of this even mean?
Next step will explain this...
I seperated this into its own post because I can't talk about pull request without talking more about process, access, rights, groups.
So you and your 5 friends are all developers, but you don't all have equal rights. You can't, things wont function that way.
One of you has to be the Project/Build Administrator.
So lets back up so we know why this is important.
Lets say I'm one of your developers right?
I hit you up and say "Hey i'm done with this change, i'm going to go put it into the master branch ok? Cool"
But i'm actually an idiot and my change ends up breaking the entire production environment.
This is where rights come into play. Most master branches are locked so that they can never be changed. But if the master branch is locked... how will my fixes ever see the light of day?
Well that's why I make a pull request. I submit my code as complete to you, the build admin, and you decide whether or not it meets the standards.
And if you say
"Ok looks good" You promote it into Branch 3: The Release Branch.Now as I said earlier, this is very very basic, because in a real company you would promote this to QA (SIT,UAT) before going to release.
So my code is in Release, but what does that mean? How can we be sure it wont break? its not on production so how what does any of this even mean?
Next step will explain this...
Last edited:
BRANCH VS ENVIRONMENT
This is where the Infrastructure and Operations side comes into play.
Man I wish I could whiteboard this for you... its much easier to explain visual than with words... but i'll try my best.
The number one mistake people make when trying to understand DevOps is that they confuse Branching Strategies with Environments.
And it makes sense, because many large companies do have a Prod/Dev/QA environment that are all fully isolated(VLAN and in some cases physically) so they assume the branching strategies are one-to-one with the environments.
The answer to that is... sometimes but not necessarily.
And when I say sometimes I mean that some companies have code that automatically pushes their commits to the proper environment. But that's an after the fact, the two are not the same inherently.
This is really hard to explain without me being there to show you but try to picture this....
Assume in the above example we are working on a website, lets call it the TheMoli.com
TheMoli.com that everyone reads and posts on lives on our server called PROD-WEB-01.
That is our public facing production web server.
However we also have a dev server called DEV-WEB-01.
This is where we work on changes to TheMoli.com like removing neg limits.
Well in order for TheMoli Dev environment to exist, someone (infrastructure) has to pull down the code from production and compile/build/run it on the Dev environment so our Dev sandbox is up to date.
This is usually done on an schedule unless your company has an advance (agile) dev process.
So my change above was to change the color of TheMoli.com's banner... that was in the Dev Branch.
I made that change in my ticket branch (offshoot of the Dev branch), but not in the actual Dev environment.
Why not? I'm working off of the Dev branch, why wouldn't my change go live in the Dev environment?
Well because everyone else who is currently working in the Dev Environment will see the exact same banner changes are making if they hydrate their ticket branches. That's why we have to have 3 branches (A release branch).
So even though i'm working off code from the Dev branch, i'm not actually editing the Dev Environment.
So how does that work? How can I edit it and see the changes without changing the environment? Simple, I have my own environment, this is where I work. Its called an IDE (Integrated Deveoplemnt Enviroment)
Many of these exists. I currently have 7 installed on my personal computer
Visual Studio, Eclipse, Netbeans, etc
You've seen them before, they look like this:
So I do my changes here, preview them here, and I think its good. That pull request I submit will pull it into the Release branch (not dev) and create what is known as a "RELEASE CANDIDATE".
This is code that has been approved, tested, etc etc and will eventually be promoted to Master.
This is where the Infrastructure and Operations side comes into play.
Man I wish I could whiteboard this for you... its much easier to explain visual than with words... but i'll try my best.
The number one mistake people make when trying to understand DevOps is that they confuse Branching Strategies with Environments.
And it makes sense, because many large companies do have a Prod/Dev/QA environment that are all fully isolated(VLAN and in some cases physically) so they assume the branching strategies are one-to-one with the environments.
The answer to that is... sometimes but not necessarily.
And when I say sometimes I mean that some companies have code that automatically pushes their commits to the proper environment. But that's an after the fact, the two are not the same inherently.
This is really hard to explain without me being there to show you but try to picture this....
Assume in the above example we are working on a website, lets call it the TheMoli.com
TheMoli.com that everyone reads and posts on lives on our server called PROD-WEB-01.
That is our public facing production web server.
However we also have a dev server called DEV-WEB-01.
This is where we work on changes to TheMoli.com like removing neg limits.
Well in order for TheMoli Dev environment to exist, someone (infrastructure) has to pull down the code from production and compile/build/run it on the Dev environment so our Dev sandbox is up to date.
This is usually done on an schedule unless your company has an advance (agile) dev process.
So my change above was to change the color of TheMoli.com's banner... that was in the Dev Branch.
I made that change in my ticket branch (offshoot of the Dev branch), but not in the actual Dev environment.
Why not? I'm working off of the Dev branch, why wouldn't my change go live in the Dev environment?
Well because everyone else who is currently working in the Dev Environment will see the exact same banner changes are making if they hydrate their ticket branches. That's why we have to have 3 branches (A release branch).
So even though i'm working off code from the Dev branch, i'm not actually editing the Dev Environment.
So how does that work? How can I edit it and see the changes without changing the environment? Simple, I have my own environment, this is where I work. Its called an IDE (Integrated Deveoplemnt Enviroment)
Many of these exists. I currently have 7 installed on my personal computer
Visual Studio, Eclipse, Netbeans, etc
You've seen them before, they look like this:
So I do my changes here, preview them here, and I think its good
. That pull request I submit will pull it into the Release branch (not dev) and create what is known as a "RELEASE CANDIDATE".This is code that has been approved, tested, etc etc and will eventually be promoted to Master.
Last edited:
Does this make sense so far?
If not lets recap.
1. Master is never edited (THIS IS PRODUCTION ENV)
2. Dev is pulled down from master on a work schedule (lets say once every 2 weeks) (THIS IS DEV ENV)
3. You get a ticket to fix something, you pull off of a Dev and make a branch based on your ticket number
4. You finish your ticket, and request a pull
5. Your superior commits your request into a QA branch.
6. Infrastructure guys implement your code into the QA environment so testers can see it live. (THIS IS QA ENV)
7. Since testers are not developing, they do not need their own separate branches. They are just told to login to the QA environment and see if the changes are good.
8. QA gives you the thumbs up and says "all good"
9. QA submits a pull request for your code to go from QA to Release (THIS DOES NOT CHANGE ENV, ONLY BRANCHES)
10. Your code sits in the Release Candidate until 2 weeks are up, during which you pat yourself on the back because you beat the sprint.
11. Once everyone's code is in and tested, the Release Candidate branch is promoted to master, and the former master branch is destroyed (see? never edited, only destroyed)
12. The new master branch code is implemented into the production environment (THIS IS PRODUCTION ENV)
13. Your code is now live on the public facing version of TheMoli.com
If not lets recap.
1. Master is never edited (THIS IS PRODUCTION ENV)
2. Dev is pulled down from master on a work schedule (lets say once every 2 weeks) (THIS IS DEV ENV)
3. You get a ticket to fix something, you pull off of a Dev and make a branch based on your ticket number
4. You finish your ticket, and request a pull
5. Your superior commits your request into a QA branch.
6. Infrastructure guys implement your code into the QA environment so testers can see it live. (THIS IS QA ENV)
7. Since testers are not developing, they do not need their own separate branches. They are just told to login to the QA environment and see if the changes are good.
8. QA gives you the thumbs up and says "all good"
9. QA submits a pull request for your code to go from QA to Release (THIS DOES NOT CHANGE ENV, ONLY BRANCHES)
10. Your code sits in the Release Candidate until 2 weeks are up, during which you pat yourself on the back because you beat the sprint.
11. Once everyone's code is in and tested, the Release Candidate branch is promoted to master, and the former master branch is destroyed (see? never edited, only destroyed)
12. The new master branch code is implemented into the production environment (THIS IS PRODUCTION ENV)
13. Your code is now live on the public facing version of TheMoli.com
Last edited:
So in all those posts, i barely scratched the surface of DevOps, I just wanted to give a quick glance at SDLC.
If we were to into devops indepth, it would take 100 pages, and it would go far more indepth into the actual infrastructure side of it (which i only mentioned in passing)
But i have a better solution if you REALLY want to learn this.
VSTS is free for 5 or fewer users
Get started tonight if you want
Plan, Code Together, & Ship Faster | Visual Studio Team Services
Honestly theres no better way to learn this stuff than to get your hands on it.
VSTS isn't the best tool, but its getting better every day.
If we were to into devops indepth, it would take 100 pages, and it would go far more indepth into the actual infrastructure side of it (which i only mentioned in passing)
But i have a better solution if you REALLY want to learn this.
VSTS is free for 5 or fewer users
Get started tonight if you want
Plan, Code Together, & Ship Faster | Visual Studio Team Services
Honestly theres no better way to learn this stuff than to get your hands on it.
VSTS isn't the best tool, but its getting better every day.
Last edited:
NYSTATEOFMIND
Superstar
Its funny you mention this... that slide above was for my presentation to a bank that i'm currently on project with
This being the 3rd bank i've worked with, i'm noticing a few patterns that can explain this.
PCI and financial compliance.
Banks have extremely rigorous technical security protocols and they are audited very often.
They are afraid of the source control aspect of devops (which I didn't get into) because this usually means storing client information on a local repository.
Now there are many ways to get around this (SQL data masking is a big one), but they are just really stubborn.
I'm serious breh, every bank i've worked with has had a CTO or Tech Director in his 60s.
These guys are fine doing development their way (which is 10x slower than DevOps).
They wont want to learn what a branching strategy is, they dont want to learn what agile process.
If they have multiple changes to make.. they just do them one at a time... locally on-prem... and hope for the best
On Tuesday I'm going to to Houston to sit down with one of these guys because their security regulation does not permit any non-domain machine access so I have to be there physically
Working with banks is the worst. Our company only does it because they pay out the ass.
NYSTATEOFMIND
Superstar
Its funny you mention this... that slide above was for my presentation to a bank that i'm currently on project with
This being the 3rd bank i've worked with, i'm noticing a few patterns that can explain this.
PCI and financial compliance.
Banks have extremely rigorous technical security protocols and they are audited very often.
They are afraid of the source control aspect of devops (which I didn't get into) because this usually means storing client information on a local repository.
Now there are many ways to get around this (SQL data masking is a big one), but they are just really stubborn.
I'm serious breh, every bank i've worked with has had a CTO or Tech Director in his 60s.
These guys are fine doing development their way (which is 10x slower than DevOps).
They wont want to learn what a branching strategy is, they dont want to learn what agile process.
If they have multiple changes to make.. they just do them one at a time... locally on-prem... and hope for the best
On Tuesday I'm going to to Houston to sit down with one of these guys because their security regulation does not permit any non-domain machine access so I have to be there physically
Working with banks is the worst. Our company only does it because they pay out the ass.
this is solid knowledge...you indirectly just helped me. I have noticed banks are slowly trying to get into devops but it just seems like a half ass measure. Capitol One seems to be the only financial firm I have seen that has adopted Devops and cloud computing in a real way.
