TNS
VOXPOP
Do You Resent AI?
If you’re a developer, do you resent generative AI’s ability to write code?
Yes, because I spent a lot of time learning how to code.
0%
Yes, because I fear that employers will replace me and/or my peers with it.
0%
Yes, because too much investment is going to AI at the expense of other needs.
0%
No, because it makes too many programming mistakes.
0%
No, because it can’t replace what I do.
0%
No, because it is a tool that will help me be more productive.
0%
No, I am a highly evolved being and resent nothing.
0%
I don’t think much about AI.
0%
CI/CD / DevOps

Dev Tools: 17 Seconds Shaved Off a Build and a Crowd Went Wild

Developers get excited over seemingly small productivity enhancements. Managers and toolmakers must look for ways optimize the software development pipeline.
May 7th, 2024 8:00am by
Featued image for: Dev Tools: 17 Seconds Shaved Off a Build and a Crowd Went Wild
Image from Melinda Nagy on Shutterstock.

The things people get excited over in the software business would make most people scratch their heads in confusion. Seemingly random events, like the announcement of extended support windows for essential enterprise software at Red Hat Summit 2024 got me reminiscing about the loudest cheer I ever heard at a developer conference.

Years ago I was a journalist and the host of the now-defunct Android Developer Conference (AnDevCon). I emceed the main stage and introduced all the keynote speakers. I told nerdy jokes and anecdotes, of course, but I cannot claim to have delighted the crowd. The various speakers presenting technical talks at the show definitely did that, but not I.

Still, none of the regular presenters caused an uproar. That honor was reserved for the folks from Google and JetBrains, who, in their lunchtime keynote, announced that the then neophyte Android Developer Studio had managed to shave 17 seconds off of every build.

The crowd went bonkers. People were throwing paper plates in the air, whooping and hollering like drunken cowboys, cheering like their team had won the FA Cup. Whistles, hoots and applause rose to a crescendo as if a famous band had just come to the stage. One guy ran up to the front of the room, high-fived the speaker and ran back to his chair.

Tool Developers, Not Just Developer Tools

I tell this story to software development managers all the time. My point isn’t that developers get excited over 17 seconds. It’s that managers and toolmakers usually don’t. They should.

They should care about that time savings because it is about far more than the actual time savings per build. While aggregated across dozens of daily builds and hundreds of developers, the time savings is significant. The greater savings, here, is mental. This is about sanity. This is about minimizing tedium. This is about quality tools in the hands of quality developers putting out quality software. This is about automating the boring stuff.

That 17-second savings for Android developers is an example of where the minds of the toolmakers were headed when they were crafting an environment for other developers. It’s a mindset of endless recursion and meta-thinking: How can we make our own software development experience better with the software we are writing?

In years past, game developers had a saying: To make a game, you must first make the tools to make your game. Today, this is far less true thanks to shared development environments and game engines.

For the modern enterprise software developer, this adage still holds true, but with a slightly different, cloud-focused bent: To make a business, you must first make the services upon which the business will be built. Or at least, connect them together somehow.

In both cases, games and enterprises, the day-to-day work of building these assets, testing them, labeling issues and builds and bugs and features… All of that work needs to be automated, or else someone is going to burn out.

And once automated, build pipelines need to be optimized. They should be productized within the organization. Your DevOps and developer enablement teams should be able to stand in front of their teams and say “We shaved 17 seconds off every build.”

The Tools that Rule

Unfortunately, building a great workflow and pipeline for your developers is not just about faster builds. In the modern hybrid cloud environment, it means tying lots of services together, which means standing up services in the first place. Naturally, building on the shoulders of open source helps limit the amount of that pipeline you’ll have to reinvent.

There are a lot of open source projects out there that can help you construct and optimize your software development pipeline for hybrid cloud delivery. Here are some links to projects and content that will help you out.

  • Podman: Podman is an open source container, pod and container image management engine. Create, start, inspect and manage pods. Play Kubernetes YAML directly with Podman, generate Kubernetes YAML from pods and deploy to existing Kubernetes environments.
  • Tekton: Tekton is a powerful and flexible open source framework for creating CI/CD systems, allowing developers to build, test and deploy across cloud providers and on-premises systems. Available commercially in OpenShift Pipelines.
  • Stackrox: The StackRox Kubernetes Security Platform performs a risk analysis of the container environment, delivers visibility and runtime alerts, and provides recommendations to proactively improve security by hardening the environment. StackRox integrates with every stage of the container life cycle: build, deploy and runtime. Available commercially as Red Hat Advanced Cluster Security for Kubernetes.
  • Quay: Quay builds, analyzes and distributes your container images. It can automate your container builds, with integration to GitHub, Bitbucket and more. Robot accounts allow you to lock down automated access and audit each deployment.
  • Argo CD: Application definitions, configurations and environments should be declarative and version-controlled. Argo CD aims to make application deployment and life cycle management automated, auditable and easy to understand.
  • KubeVirt: Virtualization inside Kubernetes. Teams that rely on existing virtual machine-based workloads are empowered to rapidly containerize applications. With virtualized workloads placed directly in development workflows, teams can decompose them over time while still using the remaining virtualized components. Available commercially as OpenShift Virtualization.
  • Konveyor: The Konveyor community helps modernize applications by providing open source tools to rehost, replatform and refactor applications to Kubernetes and cloud native technologies.
  • Quarkus: A Kubernetes native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best-of-breed Java libraries and standards. Supersonic subatomic Java.
  • Red Hat OpenShift: The trusted, comprehensive, and consistent enterprise application platform, built on open source and designed for enterprise use at scale, combined across public and private clouds. Includes all of the above with commercial support.

Once unleashed, your developers can crank out the work in ways you may not expect. Sometimes, it only takes a few simple steps, like combining the outflow of data into a single stream so developers don’t have to read issues in three different places. Other times it can take months to set up complex action and deployment automation to provide compliant production environments that can be replicated in multiple locations. Your developers probably already know what sucks. Ask them!

Whatever your needs, each time you add new features and optimizations to your development pipeline, you have a chance to delight your developers. And a delighted developer is much more likely to tackle that tricky application modernization project no one’s wanted to touch.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Kubernetes.
TNS DAILY NEWSLETTER Receive a free roundup of the most recent TNS articles in your inbox each day.