An Interview with Toshikazu Kawaguchi, Author of *Before the Coffee Gets Cold*

Application development doesn’t end when the last line of code is written. The program still needs to be tested, deployed on a properly prepared infrastructure, secured, monitored, and maintained without causing unnecessary downtime. DevOps organizes all these activities into a single, cohesive process in which developers, administrators, testers, and security specialists work toward a common goal.
It is not a single technology or role that can be reduced to simply using a few tools. DevOps is an approach to organizing software development work, based on collaboration, automation, and rapid information flow. It enables teams to make small changes more frequently, detect problems earlier, and respond more effectively to user needs.
The term “DevOps” is a combination of the words “development,” meaning software development, and“operations,” referring to its deployment and maintenance. In reality, it is a set of principles, practices, and technical solutions that integrate people, processes, and technologies throughout the entire application lifecycle. It encompasses planning, programming, testing, releasing new versions, day-to-day operations, and analyzing system performance.
In the traditional model, developers could focus on delivering new features, while administrators focused on maintaining the stability of the environment. The goals of the two groups did not always align, as the former sought change while the latter sought to mitigate risk. DevOps bridges this divide, as the team is jointly responsible for both the pace of product development and its quality, security, and reliability.
Before we get into the details, it’s worth clarifying the terminology first. The correct and widely accepted term is “DevOps.” However, the form “devop” also frequently appears in online searches, though it is most often a shorthand or an imprecise variant of the same term.
A code repository, a cloud platform, or a system that automates deployments can support DevOps, but they alone will not change the way an organization operates. The foundation lies in collaboration among people with different areas of expertise, process transparency, and shared responsibility for the outcome. A well-functioning team does not immediately abandon a finished application, but rather designs it from the outset with deployment, monitoring, and future changes in mind.
The approach to errors is also important. A failure should not lead solely to a search for someone to blame. It is more valuable to determine why the process, architecture, or security measures allowed the problem to occur, and then implement improvements. Such a culture fosters knowledge sharing and reduces the risk of hiding or, worse, downplaying difficulties.
However, DevOps does not mean that every team member has to know how to do everything. A developer can still specialize in code, a system administrator in systems, and a security expert in data protection. What changes most of all is the area of collaboration: specialists agree on requirements in advance, share information, and jointly assess the impact of implementation.
The DevOps cycle can be represented as a repeating loop. The end of one release marks the beginning of work on the next, as data from the live application feeds back to the team and influences subsequent decisions. It all starts with planning, when the team defines user needs, priorities, area changes, and quality criteria. Next, developers create small pieces of code, review them, and commit them to the version control system. The next stage involves automatically building the application and testing it for correctness to detect bugs as early as possible.
The finished package is then deployed to subsequent environments, such as test environments and, later, production environments. After deployment, the team maintains the service, ensuring its availability, performance, configuration, and security. At the same time, it monitors the application’s performance using logs, metrics, alerts, and user feedback. The feedback gathered in this way helps identify areas for improvement and influences the decisions made during the next cycle.
Of course, this workflow does not have to be identical everywhere. In banking, some changes may require formal approval, while in a small online service, implementations may occur automatically multiple times a day. The key is for the process to be repeatable, verifiable, and tailored to the level of risk.
One of the most important DevOps mechanisms is the CI/CD pipeline. The acronym CI stands for Continuous Integration. When a developer commits a change to the repository, the system automatically builds the application and runs tests. The team quickly receives feedback on whether the new code works with the rest of the product and whether it has caused any regressions.
CD can stand forContinuous Delivery orContinuous Deployment. In the first case, every properly tested version is ready for release, but the decision to make it available may be made by a person. In the second case, a valid change is automatically deployed to production. These are therefore similar concepts, but not identical.
A good pipeline isn't just about speeding up releases. It’s also meant to block faulty changes, document the deployment process, and allow for a quick rollback to the previous version. Automation acts as a quality control system here, performing repeatable tasks in the same way and leaving decisions that require judgment to humans.
Although organizations choose their own solutions, a few practices are particularly worth highlighting here.
A repository should contain more than just the application code. It can also store configuration files, infrastructure definitions, deployment scripts, and database changes. This makes it clear who made a change and when, allows the change to be reviewed before merging it into the main branch, and enables it to be rolled back if necessary.
Tests run after every significant change reduce the time between when an error occurs and when it is detected. They can check individual functions, module interactions, the user interface, performance, and security vulnerabilities. They do not eliminate manual testing, but they take over a large portion of the repetitive verification work.
| Area | Sample Solutions | Application |
| Version Control | Git, GitHub, GitLab, Bitbucket | Code Storage and Collaboration on Changes |
| CI/CD | GitHub Actions, GitLab CI/CD, Jenkins, Azure Pipelines | Building, Testing, and Deploying Applications |
| Infrastructure as Code | Terraform, Pulumi, Ansible | Automatic creation and configuration of environments |
| Monitoring and Observability | Prometheus, Grafana, OpenTelemetry | Collecting and analyzing data on system performance |
Infrastructure as Code allows you to describe servers, networks, databases, and other resources in files that can be versioned. Instead of manually configuring each environment, the team can create them based on a proven definition. This makes it easier to maintain consistency, restore the system, and scale the service.
Monitoring indicates whether known system parameters fall within the established limits. Observability, on the other hand, helps find answers even when the cause of a problem was not anticipated. This is achieved using, among other things, metrics, logs, and traces that show the flow of requests between services. Such data helps assess the health of the application from the user’s perspective and diagnose failures more quickly.
Agile helps organize product development into short iterations, quickly gather feedback, and respond to changing requirements. DevOps, in turn, builds on a similar idea of continuous improvement, but places greater emphasis on the technical path of change all the way to the production environment and subsequent maintenance.
The simplest way to put it is that Agile helps the team efficiently decide what to build and in what order, while DevOps helps them safely build, test, deploy, and monitor it. Both approaches also complement each other at the organizational level. The project manager—the person responsible for coordinating the project—must understand the interdependencies, risks, and needs of various specialists.
There is no single path to this specialization. Some people start out as programmers, system administrators, cloud specialists, automation testers, or network engineers. The common thread is a gradual understanding of the entire application lifecycle.
It’s also worth developing your skills through projects. You can create a small application, put its code under version control, add tests, package it into a container, deploy it automatically, and set up monitoring. A project like this demonstrates not only your knowledge of the tools, but also your understanding of how they interact with one another.
However, working in DevOps also requires a strong technical foundation, which you can acquire by studying at our university. The “computer science ” program atPJAIT allows students to develop, among other things, programming, design, and teamwork skills, as well as to explore topics related to software engineering, networks, distributed systems, cloud computing, and cybersecurity.
However, in DevOps, it’s not just the technical aspects that matter. You also need to understand organizational processes, business needs, information flow, and project management. Another one of ourcourses, “ field of study ” offers this perspective that combines IT, data, business, and managerial skills:Information Management atPJAIT.
Ultimately, DevOps isn’t about mechanically mastering a list of technologies. It’s the ability to view the product as a whole—from user needs, through code and infrastructure, to the reliability of the running service. Someone who understands both technology and teamwork has a solid foundation for growing into a role on DevOps teams.
Finally, it’s worth answering the question: Is it worth it? Absolutely—a DevOps specialization paves the way to some of the highest-paying roles in IT, as it combines programming, administration, cloud computing, and deployment process automation skills. According to the No Fluff Jobs report:“The IT Job Market 2024/2025,”experienced professionals can expect B2B rates of 21,800–28,000 PLN per month, and under an employment contract, a salary of 16,000–22,000 PLN gross.


