The DevOps approach came to meet the demands agile, but it has been viewed in a very superficial way (I daresay amateur).
“But how quickly respond to changes ?!”
The DevOps culture needs to be taken more seriously, not only in my opinion, but watching the direction the business is taking. Reading the article Taurion “DevOps is the foundation of the next technological revolution,” it clearly mentions the difference between companies whose business model is “analog” and companies that use a digital business model.
“What is to think digital IT? Simple: create a bimodal IT and adopt the principles of DevOps, continuous delivery! Out of complex deliveries every 4- 6 months for multiple deliveries per week or per day. How to? First simplifying and cutting red tape processes. Adopt modular programming model and based on APIs.”
Source: Computer World.[Brazilian portuguese]
In this post I want to emphasize that not always the vision of the importance of DevOps is clear to those involved. Each is worried about him. As if the outcome depended on this thought: my part is working.
Okay, but what is even DevOps?
The term DevOps came from the merger of the term “development” (dev, devel) and the term “operations” (infra, infrastructure).
His appearance was in mid-2008 during an Agile conference, where did the need for a “agile infrastructure” to meet the demands of the Agile manifesto. But only in 2009 the term DevOps was presented by Paul Hammond and John Allspaw with the work “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr.”
The approach revolves around the synergy between the development team and infrastructure. Both focusing on the result, which is the continuous improvement and sustainable product, and knowing participation in the whole through a systemic view.
The company’s business depends on it, it depends on meeting the rapidly changing software. The product will evolve, it needs to evolve, it must meet the demands, changes will come in the code, infrastructure, topology.
Dev chat: “It’s not my code, is the environment!”
Things have changed, your code needs to be built worrying about installation, the environment, the settings change. The failback strategies, unit testing, automated testing need to get out of books, articles, ie, the theory must become practice. Your development environment must be increasingly similar, or even equal, the environment that your code will find in production, is not it?
As much as you’re proud of your code and it will work as long as everything is installed correctly you need to recycle!
Op chat: “It is not my computer, it is your code!”
“It’s all right with the servers, the databases are in the air, services are active, the rules for the use of the environment are clear, we are focused on security, stability and UPTIME. If the personal development stopped inventing things, everything would be easier. “
The infra staff have to attend the changes and provide a light infrastructure, customizable and flexible so that the development team produces changes in the product without the difference between the development environment and the production environment is “the problem”.
The role of infrastructure is and has always maintain the environment so that the product is stable, and that’s right. But now we have a challenge to add, this product will grow, and it is essential that the development of this product is stable, we must avoid and reduce breakage.
And the customer?
Both teams will always have a thousand reasons to justify the mistake of another. But now we need to exercise empathy … and the customer? That using the software and often pays his salary, he will accept these reasons?
Most of the time the development team and infrastructure are the same company and is very ugly (it’s horrible) stay with the “push play” a blaming each other. Often, to an outsider, the impression is that people do not talk.
The point is communication.
The customer need this security, it needs to trust that with the same seriousness and quality that the product is hired, it will be built, maintained and evolved delivered.
Overview of DevOps approach
The goal of DevOps approach revolves around the entire product delivery, including:
- Improve the “time to market”;
- Continuous build;
- Continuous delivery:
- Automation of deployment;
- Improved frequency of deploys;
- Decreased life cycle to deploy new;
- Quality assurance:
- Environment ready for TDD;
- Decrease rate of errors in each release;
- Time decrease between the discovery and correction of a bug;
- Decreasing the time between the discovery of a production error and a new release correct, or;
- Rollback plan;
- Configuration management;
- Automation control, monitoring and orchestration;
- Infrastructure as Code;
- Dynamic environment management;
- Participation in product development settings along with the development;
- Trained staff for quick response in case of failures in the process;
- Backup strategy and restore “hot”;
There is a subject matter expert, Guto Carvalho, who defined it very well in his post What is DevOps anyway?, recommend you read to deepen.
Turning the game
Your company does not introduce any agile methodology, let alone any DevOps approach.
Remember that humanity learned to like the dinosaurs, love stories, movies, archeological research. But wait there! THEY ARE EXTINCT. There is a serious risk that you do not meet the demands agile and cease to exist.
Your company has implemented Agile but not focused on infrastructure or approach DevOps
I have a message for you “survival”. The article “DevOps is the foundation of the next technological revolution” is clear about the limitations of analog form (old) business. Give real importance to DevOps approach soon!
Your company has implemented Agile, but you still see some “wrong”.
Do not let the shuttle lands to update. As the development team or below, or the DevOps. Support for the business to simply be fluent. Find bottlenecks, solutions, tools, errors. Suggest improvements, ideas, talk, motivate.
- DevOps for Dummies. Sanjeev Sharma e Bernie Coyne;
- Agile for Dummies. Amy Silberbauer e Bernie Coyne;
- Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Jez Humble & David Farley.
- Continuous Integration: Improving Software Quality and Reducing Risk. Paul M. Duvall.
- ITRevolution.com: The Convergence of DevOps;
- [Brazilian portuguese] Guto Carvalho: What is DevOps anyway?
- [Brazilian portuguese] Computer World: DevOps is the foundation of the next technological revolution
- 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
Fabiano de Freitas Silva
Latest posts by Fabiano de Freitas Silva (see all)
- DevOps: It will be more one “fashion” or matter of SURVIVAL. - October 12, 2015
- Make Sense of your Logs: From Zero to Hero in less than an Hour! by Britta Weber - October 3, 2015
- ElasticSearch (ELK Stack) helping software quality - September 28, 2015