Hello everyone, and welcome to the Sprkl tips & tools series. In our series, we talk to prominent developers to explore how to improve developer productivity and deal with software complexity.
This time, Kostis Kapelonis, developer advocate at Codefresh, gave us quick and insightful tips on enhancing the productivity of software developers operating in modern complex environments.
Software developers are critical to a company’s success. They create products that can make or break a company’s profitability. Ensuring the well-being of these developers is crucial for any modern software organization.
Sprkl: At which phase is it best to perform testing, and what type of testing should be used? (i.e., local, CI, staging, production)
The answer is that you should have tests in all phases, starting with local tests while developing, CI tests when you commit stuff, QA tests when the application is promoted, and even smoke tests that run AFTER the application is deployed. The important thing here is to have different test suites to mix and match to get the desired results.
As a developer, for example, you should have access to some unit tests that run in less than 4 minutes and be able to run locally as fast as possible. QA tests can take much longer (maybe 20 minutes), and dedicated performance tests can take even longer. You need to use the appropriate test suite at the appropriate phase. I have seen companies where developers don’t run tests locally because it takes too much time or because they don’t trust their QA tests because they don’t cover enough functionality.
Also, all tests (apart from the local ones) should run completely automatically without human intervention. The QA department of a company should look at test results, approve/block releases, and add tests to the existing test suites. They should never run tests regularly except for sanity checks or extreme corner cases.
Sprkl: How do development teams in your organization receive feedback on deployment processes, and how does it improve developer productivity?
Kostis: The easiest metric – is the number of successful releases sent to production. The more, the merrier. If you deploy multiple times per day, you are in good shape. If you deploy once per month, then there is room for improvement.
You can formalize the deployment process by following the DORA metrics and tracking failed deployments and how long it takes to recover.
It is important to mention that developers only add value when features reach customers. That is the ultimate goal. I sometimes see companies that use vanity metrics without a visible impact on customers. This can be code coverage, the number of issues closed, sprint velocity, etc.
As a rule of thumb, if:
Then you’re doing well with your deployment process. You can continuously improve, of course.
Sprkl: How do you trace back issues? How do you debug or prevent them?
Kostis: To catch issues: implement a testing suite as the first line of defense for catching issues. Whenever you find an issue in production and fix it, you should always create a test and put it in a ‘regression’ test suite. This will guarantee that every bug is fixed once and for all.
To detect issues: implement the trilogy of traces, logs, and metrics in all your production systems. Again, the advice here is the same. Focus on real customer information (successful logins, active users, latency for common requests) and do not spend too much attention on underlying data (number of DB connections, CPU/mem capacity).
Sprkl: Do you measure developer productivity in your org? And if so, in what manner?
Kostis: It is no surprise that at Codefresh, we use Codefresh for development. The product has native support for DORA metrics.
Sprkl: Where do you think the blind spot is in the delivery process?
Kostis: There isn’t just one.
First, I notice that many companies do not use smoke tests. These tests run after deployment in production and should be able to detect serious issues.
As a second precaution, teams should learn about progressive delivery and feature flagging. If your users are detecting issues in production, it is already too late. You should have all the tools available to minimize the impact of failed deployments as soon as they happen.
Another big problem I see is configuration drift between the “staging” and production environments. Teams deploy to “staging” and assume a release will work the same way in production. But in most cases, staging and production differ a lot.
My name is Kostis Kapelonis. Good to meet you:) I’m a developer/technical writer with 15 years of experience. I have worked with both big enterprises and startups. I love testing and deployments. I am currently working for Codefresh, a company dedicated to Kubernetes deployments.
Sprkl Personal Observability platform can increase your productivity by allowing you to immediately see the impact of your code changes on the entire application while coding directly in the IDE.
If you feel like giving it a try: Start here
Enjoy your reading 8 Min Read