Technical Manager and Senior Consultant for Avenue Code, João Lima, speaks exclusively with DevOps Online about software engineering and developments.
Software engineering is inherently different from all other types of engineering. Among other things, the ease of introducing changes to completed work, the nature of software as a product that does not degrade with time, and the essential mutability of the work all set software engineering apart. In fact, agile – the primary methodology created for and adopted by the industry – goes so far as to say that the scope of any given project is open.
Large and well-known software companies such as Amazon and Netflix not only have an open product, but also deliver changes to the end user in production environments thousands of times per day. This creates the opportunity to trial run ideas, with end users testing and creating analytical data about their experience. The implications here are staggering. Thousands of times per day, these companies are creating inputs for improvements, testing new ideas in real time, and acting on the lean cycle principles (ideas – build – product, product – measure – data, data – learn – ideas) in an incredibly accelerated fashion. How? Let’s look at how a typical project might work.
Software development characteristics
It’s characteristic of contemporary software development to work in multidisciplinary teams of highly qualified people, who are often geographically distributed. In a typical medium-sized project throughout the course of a single day, you might have several developers creating hundreds of code commits to implement new features for a specific product. Concurrently, quality assurance engineers will be testing a complex road of user journeys. Changes made will be introduced at the database and integration layers before passing to business rules, security, and user interface.
Within this change-oriented scenario, our IT department has a huge responsibility to ensure everything works, maintains high performance, and has a minimal recovery time when it hits the operations team.
To summarise then, we are now working with a set of demands:
- High throughput of delivery.
- Decreased lead time (since developers must commit their changes before they become available in production to end users).
- Decrease the number of changes that result in failure in production.
- Decrease the mean time to recovery where issues arise.
As these needs continue to become more urgent, the concept of continuous delivery quickly became popularised thanks in large part to Jez Humble and David Farley, authors of Continuous Delivery. Continuous delivery is based on three foundational principles: 1) comprehensive configuration management, 2) continuous integration, and 3) continuous testing. Whereas continuous integration is primarily concerned with the correctness of the application after commits occur, continuous delivery, as a whole is more concerned with the production-readiness of the application after any commit to the main branch.
Automation: The critical element to success
The critical element to success is automation. Successful continuous delivery relies on automation for testing, configuration, infrastructure, build, packaging, deployment, release management, security, and performance monitoring. All artifacts are code-based, versioned, and part of an agile process that pushes the team to break any silos between different departments and work together toward a common goal: delivery of the application to the end user.
Clearly, continuous delivery is not easy to achieve. Many elements must work collaboratively together in a disciplined manner to follow the process correctly. Software architects must design their solutions for delivery.
Software engineers must adhere to the team coding style guides, the use of task managers, constant code review, automation scripts, pursue good coverage of unit and integration tests, and use XP, among other things. Quality assurance engineers in turn have to commit to automating their tests, while the operations teams need to code their infrastructure and release managers must code their pipelines.
In a word, this is DevOps culture. These ideas have already been play in large software companies and have made a name for themselves. In fact, DevOps as a movement has already evolved significantly in terms of tools, techniques, and even languages. But one this is for sure: regardless of how big or small your company is, DevOps is the key to success for your IT department. If you haven’t already, it’s time to begin to adopt these practices. If you have, stay vigilant as it continues to evolve.
Edited from web by Leah Alger
