Before DevOps:
In Past times, In a software development life cycle, the Primitive SDLC/ Waterfall development method was used. There were two teams, the development team and the operation team, the operation team doesn't have any idea about the operations and the operation team do not/have very less idea about development. In this method, the admin has an idea which he passes to their fellow teams and then the team started gathering information and resources for building that project. After gathering the required amount of information, now is the time to create the software architecture which was created by the software architects and could be followed by the development team for building the product.
Now after designing, the next part is to code the whole application. now the frontend & backend teams build their own parts and now it's time for integrations. when the whole application was completed, it goes down for testing, and when it fails in testing, there's no reverting back, the team has to again do the research and find the solution to the bug. then it was again sent for coding then integration and then again for testing. If it passes the whole test, it goes into production, but if it couldn't the whole process has to be repeated. Now this thing slowed down the software development life cycle.
The major problems of this approach were :
There were no provisions for changing requirements.
The team has no idea if it works until the end.
Each step ends when the next begins
The mistakes found in the later stages are more expensive to be fixed.
This was slowing down the whole release cycle and it usually takes a long time for software releases.
The people who know the least about the code are deploying it into production.
This method creates problems such as delays, frustration, long lead times, expensive late changes and operations managing unfamiliar code the software development team and the operations team were working in silos.
Evolution of Agile: Extreme programming (XP)
In 1996, Kent beck introduced the first agile method i.e. Extreme programming which was based on the interactive approach to software development and was intended to improve the software quality and responsiveness to changing customer requirements.
XP attempts to reduce the cost of changes in requirements by having multiple short development cycles, rather than a long one. In this doctrine, changes are a natural, inescapable and desirable aspect of software-development projects, and should be planned for, instead of attempting to define a stable set of requirements.
Extreme programming also introduces several basic values, principles and practices on top of the agile methodology.
XP achieves these goals by implementing several practices, including:
Test-driven development (TDD): XP uses TDD to ensure that the code is correct, complete, and maintainable. This involves writing automated tests before writing any code and then writing code to pass the tests.
Pair programming: XP encourages developers to work in pairs, which helps to promote knowledge sharing, reduce errors, and improve code quality.
Continuous integration: XP uses continuous integration to ensure that the code is always working. This involves merging code changes into a shared repository frequently and running automated tests to verify that the changes have not introduced any issues.
Refactoring: XP encourages developers to refactor the code as needed to ensure that it remains simple, maintainable, and efficient.
It was a very good approach, but it still had some drawbacks. Extreme Programming (XP) has been criticized for a number of reasons. Some of the common criticisms of XP are:
Lack of documentation: XP emphasizes face-to-face communication over written documentation. While this can be effective for small teams and simple projects, it can be difficult to scale for larger teams and more complex projects. A lack of documentation can make it difficult for new team members to get up to speed and can make it harder to maintain the code in the long term.
Overemphasis on testing: XP places a heavy emphasis on testing, to the point where some critics argue that it can slow down the development process. Writing tests before writing code can also be difficult for some developers, and can lead to a focus on passing tests rather than delivering functionality.
Difficulty in managing scope: XP is designed to be flexible and to accommodate changing requirements, but this can make it difficult to manage scope and timelines. It can be challenging to prioritize features and to ensure that the team is delivering value to the customer on time.
Dependency on team dynamics: XP relies heavily on the team dynamic and can be challenging to implement if the team is not cohesive or does not have the necessary skills. This can make it difficult to scale XP for larger teams or to implement it in organizations that do not have a strong culture of collaboration and continuous improvement.
While these criticisms are valid, it's important to note that XP has also been successful in many cases. It can be an effective approach for small, agile teams working on projects with changing requirements, and can lead to high-quality, maintainable code. Ultimately, the effectiveness of XP will depend on the specific context and the needs of the organization.
DevOps : a new culture in SLDC
A brief history of evolution :
In 2007, Patrick Debois (also known as the father of DevOps) recognized the problem that the development and and operations teams are working ineffectively and in silos(not together). so, he came up with the idea of following a new culture in a software development methodology i.e. DevOps.
He started the DevOps movement with the simple idea of getting development and operations to work better together. In 2016, he also published his book "The DevOps Handbook"
In 2009, John Allspaw at the Velocity conference described an innovative approach to managing development and operations flicker to cover over 10 deployments per day when many companies are completing fewer than 1 deployment every six months. This was the key moment in the growth of DevOps.
What exactly DevOps is?
DevOps is a practice of Development and operations engineers working together into an entire software development life cycle, following lean and agile principles that allow them to deliver quality software in a rapid and continuous manner.
It's not just Devs and ops working together, but it's a cultural change and a different way to work.
The essential characteristics of DevOps is cultural change, automated pipelines, infrastructure as code, immutable infrastructure, cloud-native application design, the ecosystem of containers and how to deploy with immutable infrastructure.
The DevOps workflow typically involves the following stages:
Plan: This stage involves defining the goals, requirements, and timelines for the project.
Code: In this stage, developers write and test their code using version control systems such as Git.
Build: In this stage, the code is compiled, tested, and packaged into a deployable format.
Test: In this stage, automated and manual tests are performed to ensure that the software meets the requirements.
Deploy: In this stage, the software is released to production or a staging environment.
Operate: In this stage, the software is monitored and maintained to ensure that it continues to function as expected.
Monitor: In this stage, metrics are collected to measure the performance of the software and identify areas for improvement.
How it solves the problem?
So, it worked on the principle that the developers should have some knowledge about operations and the operation team should have some development knowledge. so when the software was ready for production the operations could better understand the architecture of the code and how it works, so that they could create a more robust environment to test and deploy it. And if they got some issues during production, they could eventually able to understand the problem and could take better decisions.
So, the deployment that was taking more than 2 months (in the waterfall deployment) due to working in silos can be resolved within 1 or 2 days because Devs and ops are working together under the same roof and they both have some knowledge about each other's jobs. So, as a result, the release cycle became faster.
Conclusion:
This is how the entire software development life cycle evolved over time and it is evolving day by day. There's a new buzz word that we are hearing more often i.e. Platform engineering. I'll take about that in my upcoming blogs.