Developers love their logging. Virtually every programming language lets you create additional output for your application in the form of logs. It’s an easy way to debug code and it’s understood even by junior developers. Logs tell you if a call to a certain method has failed if a specific line of code has been reached during execution, or when to get a local variable’s value. And who could blame them?
The process of writing code has evolved—is your organization ready for the demands of today’s software development? The individual development steps haven’t changed much. Code is still written, tested, integrated, and released. But the way these steps are accomplished, how code is handed off from one stage to another, and how it is released, is vastly different. The goal today is to get applications out the door faster.
I'm one of the fortunate people who have witnessed the (r)evolution of software development and delivery throughout my career. From programs deployed in local racks to serverless running with the pay-as-you-go paradigm, we've seen a breakthrough in computing in a relatively short time.
2009 has a special place in the history of software and technology as it is the year that formally saw the birth of DevOps. In June of that year, John Allspaw and Paul Hammond presented their talk, 10 Deploys a Day: Dev and Ops Cooperation at Flicker” at the O’Reilly Velocity conference. Legend has it that Patrick Debois was not physically present at the talk, however, he did see the recording of the presentation.
Developers are often discouraged by the amount of time spent debugging code. Time spent debugging is time away from developing interesting new features. So how can this pain point be alleviated? The first way to cut down on time spent debugging is to write better code. Code without any of those tricky, off-by-one errors and null object dereferences. Ideal code. But we all know it’s impossible to write perfect code on the first try. Besides, requirements change.
How can your team work faster to identify problems in their code? And more importantly, how can you reduce, eliminate, or solve problems while building a culture of collaboration rather than blame? Today’s fast-paced DevOps environments center around the CI/CD pipeline, tuned to give your team quick feedback loops and let you release even multiple times per day.
Today's applications are more distributed, and today's world is more remote, than ever. But developers just don't have the same freedom and comfort that they’ve become accustomed to when developing in remote environments. One of the biggest challenges of remote environments is having the ability to debug applications.
In modern software development practices, it’s imperative to understand continuous integration (CI) and continuous delivery/deployment (CD). The goal of a CI/CD pipeline is to allow developers to apply new software changes to a production environment quickly and safely in order to generate business value. Understanding the difference between continuous integration, delivery, and deployment is important for both engineers and business leaders.
According to a survey conducted by Jetbrains, Spring Boot is the top Java framework for developing web applications. Spring Boot applications are usually deployed on a dedicated server and/or container via necessary orchestration. Normally, this inevitably includes the work of managing the infrastructure and scalability of the application.
