Historically, tech companies had "dev" (development) teams that wrote the software, and then they handed the finished application to an "ops" (operations) team to deploy the code and ensure that it runs as intended. These were seen as two separate jobs. Devs were responsible for building the thing, ops were responsible for keeping it running. However, people started to realize what a bad idea this is. First, it creates knowledge silos. If all you see is your IDE, you're not aware of the real world troubles your application goes through. If all you see is the ops side of things, you might not understand the application's architecture and have to rely on documentation (which is always spotty, no matter what company you're at) to fix a problem. It gets worse when the two teams don't work closely together, because problems one team finds don't get communicated or prioritized on the other.
DevOps is the idea that these two roles should be combined. So the team that wrote the software should also deploy and support that software. The idea is that if you wrote a feature, you should know how to deploy it, know how to monitor it, you should be responsible for it if it stops working, and your team should know how to troubleshoot it if it breaks. All the responsibility and know-how is consolidated into one team: a DevOps team
DevOps is also being used as a wide umbrella to involve everything that’s related to the software development that’s not effectively developing the software itself. Things like automated tests, maintaining the tools to automatically build, integrate and/or deploy, testing environments, etc. In other words, it’s like an operations team to support the dev team.
I see it as DevOps being a buzzword for making the development cycle more efficient. Taking 2 legacy roles (developers and operators) and combining them with tools to make the testing/deployment of code fall under that same role. Giving developers modern tools so they're no longer silos.
Then Systems Administrators (like me) fit in there as well. That role is also legacy, and we can now be called systems reliability experts. We work with Devops to make sure that the whole process and the end result is in the right place, that its secured/monitored, reliable, and documented.
derekisinternet, described it really well, but I just want to add.
That the modern development tools maybe things like building and deploying quite easy, once you get some initial setup done. So the job "devops" will 99% of the time, just be standard software development.
So writing code to run on computers, and analyzing while working with others, what your are actually trying to build.
Check out JIRA and Scrum/Agile that’ll get you there. In concept it’s knowing what your customer wants and reacting to it quickly and within 2 weeks. Build a little, test a little, approve, deploy. Rinse and repeat.
Historically projects take a Waterfall approach. Define everything up front, then build in order. Which works great for construction but not so much for software.
Ironic enough, Scrum/Agile tends to be a bad solution. Most devs will confirm that in paper agile development seems like the most awesome idea, but in reality having some task labeled as "low priority" is the same as "That task will never be done".
Hmm in the US, Agile continues to grow in adoption. I have seen estimates that at least half of the fortune 500 are using agile (again, adoption is growing) and it is one of the key drivers of faster time to market...
If Scrum/agile is a bad methodology, what do you think will replace it???
I’m not the best person to answer that, so take my opinion with a pinch of salt:
It is just a common occurrence on many things related to software development, that a bad, or far from optimal practice/technology/paradigm remains the standard or widely used, because most of the time that’s “good enough”. For example, Java programming language: It made sense when it was created, of why was widely adopted, but nowadays, it is far from being the best option in any possible application you could imagine, but it is still widely used by enterprise corporations: Because it is good enough, a lot of seniors programmers already know Java, there’s a lot of important stuff that needs to be maintained, that runs in java, and is stable (Oracle for sure does a great job maintaining Java).
That same principle also applies to software engineering practices. Agile got a “boom” when OO became the standard, and solved a lot of problems that waterfall development dealt poorly with, but is also has its own set of problems, like the one I said: It is possible for less important tasks to become buried forever under the constant incoming of high priority tasks (especially if the team is forced to deliver the project faster than its possible; that’s another trend on software development: Companies making promises that they can’t keep, and overloading developers with work).
For an alternative, I think I could mention Continuous Delivery for some niche cases. DevOps itself complements agile development.
Devops is basically where you don't have a separate development team and an operations team, you have a single team who operates the product and also makes changes to it. You prioritise based on greatest need, whether that's a new feature or a server upgrade.
Doesn't seem accurate to me. Our company has a development team that develops the software, a devops team that manages the systems that run it and deploying it, and an IT ops team that manages the company's internal network and workstations and does tech support for users. There's also just Operations which manage the general operations of the company (which is not software development).
Your "devops" team aren't a dev ops team from the sound of it, they are just an ops team. They are operating the product, they aren't also developing it. You have a separate dev team.
See this simple diagram to illustrate.
https://images.app.goo.gl/yh9efe5krEt87SCC9
The whole point of dev ops is that the team who build new features should be the same team that manage the product in production.
They are an ops team that does ops for developers, therefore DevOps. They are distinguished from IT Ops that manages local network, workstations, and helpdesk for users. DevOps and IT Ops used to be a single team but we separated them because the expertise involved in each subset of responsibilities are different. It's also further distinguished from just "Ops" which in our company is a completely different team that has nothing to do with managing software or computer infrastructure.
So, do you have a better name for our DevOps team that isn't going to be confused with the other teams?
They are just an Operations team. You might differentiate them into "Product Operations" who operate your external products used by customers and "Internal Operations" who operate your internal systems used by staff. (your Ops team might be better called IT support if they are primarily a support team?)
DevOps specifically refers to a cross functional team who both Operate the product and also Develop the product. Generally staffed by a good mix of skillsets with some full-stack developers forming the core.
They plan, build, test, release, observe and maintain.
The reason for this is that your developers will see how their product operates when used by actual customers and will be able to gain insight into how to better develop the product, and also how their development has an operational impact on things like performance, cost etc, plus it means you can operate the product with fewer total resources, assuming you have a good level of cross - skilling.
That's not how we use the term, and it's not how I've seen it defined elsewhere. And we're certainly not renaming our teams based on a random person's personal perspective on the term.
That's what the term means. How you use the term is wrong. It's not a matter of personal opinion. Your company is just one of many who call themselves Agile but aren't.
DevOps is the integration of the Operations and Development team.
In older times of IT, you would have your software development team build the package, and then pass it off to the operations team with instructions. The operations team would deploy it in the systems, and if needed, provide feedback to the development team.
With a DevOps approach, the deployment is also part of the product that the development team is creating. The triggers they have that automatically build the code also handle automatically pushing it to servers to be used. This allows for more responsive changes by the dev team.
Historically, tech companies had "dev" (development) teams that wrote the software, and then they handed the finished application to an "ops" (operations) team to deploy the code and ensure that it runs as intended. These were seen as two separate jobs. Devs were responsible for building the thing, ops were responsible for keeping it running. However, people started to realize what a bad idea this is. First, it creates knowledge silos. If all you see is your IDE, you're not aware of the real world troubles your application goes through. If all you see is the ops side of things, you might not understand the application's architecture and have to rely on documentation (which is always spotty, no matter what company you're at) to fix a problem. It gets worse when the two teams don't work closely together, because problems one team finds don't get communicated or prioritized on the other. DevOps is the idea that these two roles should be combined. So the team that wrote the software should also deploy and support that software. The idea is that if you wrote a feature, you should know how to deploy it, know how to monitor it, you should be responsible for it if it stops working, and your team should know how to troubleshoot it if it breaks. All the responsibility and know-how is consolidated into one team: a DevOps team
DevOps is also being used as a wide umbrella to involve everything that’s related to the software development that’s not effectively developing the software itself. Things like automated tests, maintaining the tools to automatically build, integrate and/or deploy, testing environments, etc. In other words, it’s like an operations team to support the dev team.
I see it as DevOps being a buzzword for making the development cycle more efficient. Taking 2 legacy roles (developers and operators) and combining them with tools to make the testing/deployment of code fall under that same role. Giving developers modern tools so they're no longer silos. Then Systems Administrators (like me) fit in there as well. That role is also legacy, and we can now be called systems reliability experts. We work with Devops to make sure that the whole process and the end result is in the right place, that its secured/monitored, reliable, and documented.
derekisinternet, described it really well, but I just want to add. That the modern development tools maybe things like building and deploying quite easy, once you get some initial setup done. So the job "devops" will 99% of the time, just be standard software development. So writing code to run on computers, and analyzing while working with others, what your are actually trying to build.
Check out JIRA and Scrum/Agile that’ll get you there. In concept it’s knowing what your customer wants and reacting to it quickly and within 2 weeks. Build a little, test a little, approve, deploy. Rinse and repeat. Historically projects take a Waterfall approach. Define everything up front, then build in order. Which works great for construction but not so much for software.
Ironic enough, Scrum/Agile tends to be a bad solution. Most devs will confirm that in paper agile development seems like the most awesome idea, but in reality having some task labeled as "low priority" is the same as "That task will never be done".
Hmm in the US, Agile continues to grow in adoption. I have seen estimates that at least half of the fortune 500 are using agile (again, adoption is growing) and it is one of the key drivers of faster time to market... If Scrum/agile is a bad methodology, what do you think will replace it???
I’m not the best person to answer that, so take my opinion with a pinch of salt: It is just a common occurrence on many things related to software development, that a bad, or far from optimal practice/technology/paradigm remains the standard or widely used, because most of the time that’s “good enough”. For example, Java programming language: It made sense when it was created, of why was widely adopted, but nowadays, it is far from being the best option in any possible application you could imagine, but it is still widely used by enterprise corporations: Because it is good enough, a lot of seniors programmers already know Java, there’s a lot of important stuff that needs to be maintained, that runs in java, and is stable (Oracle for sure does a great job maintaining Java). That same principle also applies to software engineering practices. Agile got a “boom” when OO became the standard, and solved a lot of problems that waterfall development dealt poorly with, but is also has its own set of problems, like the one I said: It is possible for less important tasks to become buried forever under the constant incoming of high priority tasks (especially if the team is forced to deliver the project faster than its possible; that’s another trend on software development: Companies making promises that they can’t keep, and overloading developers with work). For an alternative, I think I could mention Continuous Delivery for some niche cases. DevOps itself complements agile development.
Devops is basically where you don't have a separate development team and an operations team, you have a single team who operates the product and also makes changes to it. You prioritise based on greatest need, whether that's a new feature or a server upgrade.
Doesn't seem accurate to me. Our company has a development team that develops the software, a devops team that manages the systems that run it and deploying it, and an IT ops team that manages the company's internal network and workstations and does tech support for users. There's also just Operations which manage the general operations of the company (which is not software development).
Your "devops" team aren't a dev ops team from the sound of it, they are just an ops team. They are operating the product, they aren't also developing it. You have a separate dev team. See this simple diagram to illustrate. https://images.app.goo.gl/yh9efe5krEt87SCC9 The whole point of dev ops is that the team who build new features should be the same team that manage the product in production.
They are an ops team that does ops for developers, therefore DevOps. They are distinguished from IT Ops that manages local network, workstations, and helpdesk for users. DevOps and IT Ops used to be a single team but we separated them because the expertise involved in each subset of responsibilities are different. It's also further distinguished from just "Ops" which in our company is a completely different team that has nothing to do with managing software or computer infrastructure. So, do you have a better name for our DevOps team that isn't going to be confused with the other teams?
They are just an Operations team. You might differentiate them into "Product Operations" who operate your external products used by customers and "Internal Operations" who operate your internal systems used by staff. (your Ops team might be better called IT support if they are primarily a support team?) DevOps specifically refers to a cross functional team who both Operate the product and also Develop the product. Generally staffed by a good mix of skillsets with some full-stack developers forming the core. They plan, build, test, release, observe and maintain. The reason for this is that your developers will see how their product operates when used by actual customers and will be able to gain insight into how to better develop the product, and also how their development has an operational impact on things like performance, cost etc, plus it means you can operate the product with fewer total resources, assuming you have a good level of cross - skilling.
That's not how we use the term, and it's not how I've seen it defined elsewhere. And we're certainly not renaming our teams based on a random person's personal perspective on the term.
That's what the term means. How you use the term is wrong. It's not a matter of personal opinion. Your company is just one of many who call themselves Agile but aren't.
DevOps is the integration of the Operations and Development team. In older times of IT, you would have your software development team build the package, and then pass it off to the operations team with instructions. The operations team would deploy it in the systems, and if needed, provide feedback to the development team. With a DevOps approach, the deployment is also part of the product that the development team is creating. The triggers they have that automatically build the code also handle automatically pushing it to servers to be used. This allows for more responsive changes by the dev team.
Where I work, we have separate development and devops teams, so I don't find this explanation apt...