How do you evaluate DevOps tools and choose the best one for your company?
Questions often arise like, is the tool flexible, with support for any language? Does it provide out-of-the-box integration to many of the common tools we use? These are important considerations to find DevOps tools that fit your needs.
One definition of insanity is doing the same thing over and over again, but expecting a different result. Many development teams face disaster every time they try to release software. This seems to get worse and worse with longer code freezes, more integration hell, more slipped ship dates and more deathmarches. One region of the code that always seems to evade scrutiny is the build infrastructure itself.
Technical debt in your build Infrastructure
People often think about the accumulation of “technical debt” in software. This can result in a healthy rearchitecting or refactoring of code bases in an attempt to “clean up. But a similar kind of debt can appear in the build infrastructure itself.
For some reason it has become the norm to accept technical debt in the build pipeline as part of software development. Decisions are made, not based on whether they are good or bad, but depending on if they can meet the deadline of the next release. Technical debt, similar to financial debt, comes with interest. Yet, unlike financial debt, the software industry has tolerated very high interest payments for a long time.
Why is this behavior largely accepted? Perhaps it boils down to what can be measured. But, just because we cannot accurately measure it, doesn’t mean it’s not there. It’s there… like a big fat elephant in the room that needs to be addressed.
Address the Big Elephant in the room
Using Gradle you can avoid accumulating technical debt in the software development pipeline. Gradle comes with a Build specific Domain Language (DSL) that allows for a maximum of automation and expressiveness while maintaining an extremely readable, maintainable and concise build script. Additionally, with the new upcoming SaaS service Gradle.com, you will be able to see additional analytics about how your build is executed. We call it “see inside your build”. With these insights you can discover opportunities to speed up your build, help you diagnose and fix problems as a team, share your build data, and reduce technical debt. At Gradle, we believe that software development can no longer afford to accept technical debt in the build pipeline as the norm.
Because of the explosion of complexity in modern software, these problems are only going to get worse. Projects are getting larger with more external dependencies including an explosion of available open source libraries. This is a good thing but it increases the number of upstream dependencies, especially transitive dependencies. Trends like containerization with Docker, distributed computing with Mesos, Kubernetes and the emergence of microservices increase complexity of requirements and developers are faced with new demands every day. The industry is changing at a rapid rate, and companies that cannot keep up will cease to be competitive. Some of the best software teams in the world like LinkedIn , Netflix , Unity 3D , and others have seen the future of software development, evaluated DevOps tools, and have chosen Gradle. In doing so, they have set new standards for how to create Continuous Delivery pipelines and realize continuous improvement. For Android developers, you can learn more about how other companies, like Ticketmaster, have implemented Gradle to reduce technical debt here .
Fast Cadence of Releases
The Gradle team builds the Gradle open source project using Gradle itself. This process reduces technical debt in the continuous delivery build pipeline. The build can automate more and more tasks without becoming an unmanageable mess due to the build specific programming language (domain specific language or DSL), and robust ecosystem of over 800 plugins. This is demonstrated by the frequency in which Gradle publishes new versions. Since the release of version 1.1 in July of 2012, Gradle has a released a new version every 55 days on average. Last year alone Gradle published 8 releases starting with version 2.3 and ending with version 2.10. Maven, in comparison, released 3 versions in 2015. Gradle continues to release new features and performance improvements at fast cadence. Why does this matter? Users report that improvements to the DSL result in even shorter and more maintainable build scripts without losing expressiveness and automation power. In these recent releases Gradle delivered features that have helped speed up development, and free up time to tackle technical debt. For instance continuous build, recently released with Gradle 2.11 now behaves like a true local build server. Continuous build was first introduced in Gradle 2.5 and allows you to continuously work by automatically re-triggering builds when things change. Additionally, the most recent release, version 2.12 shows significant optimizations to build script compilation. You can expect reductions in startup times of up to 20% when running a build for the first time or after making changes to build scripts .
The Gradle build continues to get faster and faster because of the hard performance work by the Gradle engineering team and the community. We are committed to continuing the frequent releases of new versions and features that help speed up development and free up developer time to tackle technical debt.
Download Gradle’slatest version here.