Getting “There” from here: understanding the requirements of modern build automation infrastructure in the Age of Continuous Delivery
Introduction:
Devops, Containers, Mobile, SaaS, APIs and other forces are creating an inflection point in the industry where there are two ways to build software–the old way and the new way.
The new way: leads to Continuous Integration (CI) and Continuous Delivery (CD) of software and a continuously improving software delivery pipeline. Things get better and better.
The old way: leads to ever-increasing inefficiency, cost, risk and complexity through increasing build times, long code freezes, death marches, build fragmentation and unmaintainable builds. Unmanageable dependencies leading to fragile production environments or code forking and to an integration hell with bug regressions and slipped ship dates. Things get worse and worse.
People are often at a loss to understand how a build automation infrastructure can serve as a platform for Continuous Delivery and how choosing the right platform can result in ultimate success or failure of your software production efforts. This article will establish key criteria for understanding how to select a build automation infrastructure suitable for modern software development requirements.
Getting to Continuous Delivery and Continuous Improvement.
What characterizes Continuous Delivery (CD) of software? We can rely on Martin Fowler’s definition which says that the essential characteristic of Continuous Delivery is the ability for teams to keep producing valuable software in short cycles and ensure that the software can be reliably released at any time. According to Martin, Continuous Delivery is best when it provides fast feedback about what changes are deployable, and that maintaining this speed often needs the creation of an Automatic Build and Test Pipeline.
The challenge of building build (and test) automation is that rapid changes to the industry as well as the growth of your team and pipeline automation requirements rapidly outstrips the ability of many tools to deliver maintainable automation at scale.
The essential question for understanding a modern build system is how far that system can carry your organization in the age of Continuous Delivery.
Why Invest At All?
If it ain’t broke, why fix it? Two main reasons.
First of all your development team is bleeding red ink every day. Lost productivity due to poor automation is costing hundreds of hours of lost productivity even in small teams. A quick back-of-the-envelope calculation can show you that A five percent increase in developer productivity can save a team of 200 developers a million dollars annually. Having low developer productivity is wonderful for the worst slackers and low performers in the company, but terrible for the highest performers. You may even experience loss of your best developers who just want to write code and change things quickly.
Secondly, every penny you throw into optimizing a non-scalable build platform will have to be re-spent when that system needs to be replaced. This is simply because trying to get to Build Automation at scale in the Age of Continuous Delivery requires a Build Automation Platform that was designed for this environment.
If you are not on the path to continuous improvement, you are on the path of continuous decline. You will be faced with mounting technical debt and the inability to compete in the marketplace for your products, but also for Engineering talent.
Investing in Automation:
The key criteria for evaluating any IT effort is to understand the Return on Investment (ROI). The idea investment profile for build automation tooling is the ability to invest more and more into the platform and to keep getting the benefits.
The pattern we are talking about is the ability to invest initially as well as deeply. The reason for this is you are investing in continuous improvement. If you invest initially and get some improvement, but at some point the ability to improve grinds to a halt, then you have chosen the wrong platform. Continuous improvement requires that you be able to improve today, but also that you will not hit fundamental discontinuities in the future.
In other words, if you invest a “dollar” today, you should get “ten cents” out every month for the rest of your life. But if you invest 10 million dollars over the next 10 years, you should get a million dollars of return every month for the rest of your life.
The questions technical leaders need to ask are:
Are we committed to Continuous Delivery and Continuous Improvement?
Will our Build Automation Platform enable Continuous Delivery?
As requirements increase, will our platform support those new requirements?
Or will there be painful discontinuities and disruptions?
As we scale, will our platform be maintainable?
Is the Build Automation Platform *itself* improving continuously?
Any build automation platform worthy of your organization’s investment should start paying back quickly… but the return should scale over time, eventually reaching the highest levels of automation seen at the best software companies in the world. You may not reach these levels of automation right away, but you need to understand that there are build automation platforms that can reach these heights, and that there are those that can’t.
The hard thing is to keep improving over the long term and eventually attain an industrial-scale automation pipeline. If you are committed to investing in automation on top of a platform that is not built for the Age of Continuous Delivery, there will be huge discontinuities and your build system will be in a state of continuous decline eventually culminating in a brick wall.
How to Invest?
The good news is that there is a smart investment pattern that lies between wholesale rip-and-replace and doing nothing.
Organizations wanting to experiment with Continuous Delivery and Build Automation often begin by developing a single project pilot, often with a team building something new. This allows the organization to test the capabilities of a new build system and process and to understand better how such a system can benefit you.
Another option is to do a project migration, either on your own or assisted by Gradle Inc. consulting services. Another piece of good news is that you can begin quickly by taking advantage of the Maven and Ant integrations already built in to Gradle. Gradle can quickly be used with Maven and Ant, and over time can be made to improve towards the eventual target state.
Once the pilot team has achieved success, it becomes a no-brainer to roll these gains out across your Enterprise.
Modern Build Platforms: Expressive and Concise
One way to understand a build platform is to see how expressive and concise it is as your needs scale. To understand this a little better, you can think about how these two values result in convergence or divergence over time.
What do we mean?
By Expressive we mean “can you express a complex idea in this platform”. Of course by having scripting or programming in a platform including forking parts of it, it is theoretically possible to express virtually anything. This brings us to the other term, Concise. A concise expression means not only is it possible to express a complex idea, but that it can be expressed in a compact, readable, understandable and maintainable way.
Historically there has been a natural tension between these two terms. As your needs scale, the builds associated with your software tend to demand more Expressiveness. As soon as you start to create more complex expressions, Conciseness will suffer. Therefore with the previous generation of build tools you are resigned to either being stuck with severely limited capability or ever-increasing complexity without bound and unmaintainablility.
The Maven Problem: Being Concise Without Being Expressive
With Maven, you will eventually hit a wall.
Some people just flat-out stop adding any more automation to their build pipeline. This leaves developers stuck in an unproductive environment where their needs are not being met.
The alternative for Maven users is to hack around the limitations. This means that an ever-increasing amount of the build is created outside of the build system in the form of unmaintainable scripts scattered through the organization in many different languages. This brings you over to a system that is expressive, but tends to grow in complexity without bound.
The penalty of this type of system is that it is unmaintainable and when it fails it’s often unclear where the institutional knowledge exists as to how you can fix it. It becomes very complex to onboard developers and nobody understands exactly what is happening.
The Ant Problem: Being Expressive Without Being Concise
Ant has almost the opposite problem. Ant/Ivy allows you to express very complex automation requirements. However it has the unfortunate tendency to become increasingly and forbiddingly complex over time.
According to Viktor Farcic and Jordi Falguera of “Technology Conversations” with regards to Ant:
Major drawback was XML as the format to write build scripts. XML, being hierarchical in nature, is not a good fit for procedural programming approach Ant uses. Another problem with Ant is that its XML tends to become unmanageably big when used with all but very small projects.
A number of sophisticated Enterprises have gotten a ways down the road in terms of automation features with Ant, but find themselves in trouble when it comes to transparency, maintainability and conciseness of the build.
Why is Gradle Able to Remain Concise?
People say that Eskimos have 57 words for snow. Why is that? Because snow figures pretty significantly in what they need to communicate about.
Gradle has a build-specific programming language. This means that the Gradle language can continuously be expanded to concisely describe anything that touches build automation. Gradle may eventually end up with 57 words for “repository”. This produces very concise expression because the language is able to expand to accommodate a very large expressive space–and by using specialized expressions that are specific to the domain of builds, it can do so in an incredibly concise and readable way.
This means that the Gradle Build Language is a Domain Specific Language (DSL), optimized for expressions around builds.
And How Expressive is Gradle?
The same property, the build specific language enables Gradle to express more and more sophisticated situations that are encountered in build automation. On the way to “There” most software teams encounter serious challenges that require increases in many areas of software automation.
One direct measure of Expressiveness is to understand specific features and how Maven compares to Gradle in a side-by-side comparison table.
The other way to understand Expressiveness is to take a look at the road ahead for your software teams. Based on our experience, Enterprise software teams at scale hit many if not all of the following problems as they reach peak efficiency in build automation. If your tool is unable to concisely express these important future automation requirements (or if it’s unable to express them at all), your team will encounter a brick wall on the way to software success (“There”).
Here are some examples of automation requirements your team may encounter along the way:
Provisioning development environments
Automate VCS operations across many repositories
Database Migrations/Refactoring
Integrating Containers during the development lifecycle
Test Automation
Unit & Integration tests
Fragile Integration Tests
Multiple Types of Integration Test executed at different phases of the lifecycle.
Run integration tests against multiple environments (JDK version, different Databases, …)
Performance Regression Tests that enforce certain performance standards
Complex Test Fixture Set Up & Shutdown as part of the integration test lifecycle
Release Automation
Continuous Integration
Full Understanding of upstream and downstream dependencies
Staging specific rules for dependency selection.
Custom metadata that models the staging process as first class citizen during dependency resolution.
Dependencies
Central Versioning Strategies
Whitelisting/Blacklisting with warning periods until versions get disabled
Conflict Resolution for libraries that had a name change.
Legacy Binary Stores with or without legacy metadata formats
Target Platforms (e.g. Android, iOS, Linux, MacOS, Windows , Application Servers, different devices, etc.)
Shippable variants without forking or artificial separation (i.e. Free vs Paid, “Pro”, Partner versions, Versions for different Geo’s)
Polyglot Codebases (Java, Android Java, Obj-C, C++, C#, Scala, etc.)
Source & Resource Generation
Documentation
Inject integration tested live code including its live output into the docs.
Integrate any toolchain for document generation
Inject build data into the documentation (Test Reports, Version Numbers, …)
Publish documentation to any destination
Standardization across Enterprise builds
Cross Language Dependency Management
Pre-Configured Build Environments
Auto Provisioning of Build Environments
Enforce any company specific policies across teams
Seamless and deep integration with existing builds and build infrastructure
On your journey to “There” you will encounter many if not all of these problems.
Gradle will have your back at each one of these twists and turns on the way to Build Happiness (“There”), and will provide return on investment for even the most advanced Continuous Delivery teams.
Will All Projects Have All These Requirements?
No. First off if your team is not interested in Continuous Delivery and Build Automation, you may not hit many or most of these requirements. There will also certainly be examples of software projects that will not hit these brick walls on the road to software success (“There”).
There may certain cases where open source projects can safely stay on Maven, for example.
This is why discernment is key.
What is needed is for technical leaders to understand specifically the problems their teams will have. Not just today, but going into the future.
The Industry Also Has Ever-Increasing Requirements
Not only will your growing project keep creating more and more complex build requirements, but The software industry as a whole is changing rapidly, and the new requirements demand new approaches to how software is built. Software has changed so radically over the past 10 years that the methods used to build it had to be changed significantly.
What happened to Software?
Software ate the world. This means that all companies must see themselves as software companies, and must embrace software delivery as a core competency, it also means that code bases are growing by leaps and bounds. Code bases can double in size in a year or less.
Android and iOS happened. This means more target platforms and more management of different releasable versions often including free and paid versions of the same app. In addition, the concept of a complete rewrite “version 2.0” is dysfunctional in the mobile era. Bugfixes and changes need to appear quickly and continuously or you will lose your users.
SaaS happened. More and more software is being delivered as-a-service, either through a UI or an API. This dovetails nicely with continuous delivery as the ability to continuously improve your service becomes a competitive advantage.
Github happened. Increasingly, big projects are a fully distributed mix of open and closed-source components. Social coding is now the norm. This creates a much more complex situation with respect to dependency management and Continuous Integration (CI).
DevOps happened. The ability to virtualize and containerize software stacks and innovations such as microservices creates a new way to think about software deployment and begins to unify the traditionally separate worlds of Development and IT Operations.
These are just a few of many significant changes that are creating pressure for change in how software is built. The agility that comes from implementing continuous delivery is becoming a competitive baseline–and companies unable to ship new features will cease to be competitive and eventually be wiped out by those who can.
The industry is changing quickly. Any modern build tool needs to evolve quickly to keep pace with these changes. The rate of improvement and investment in Gradle core is far outstripping Maven, and this evolution of Gradle is supported by its design. Gradle improves quickly and has the capacity to get deeper and deeper over time.
And the Competitive Bar Got Higher.
Increasingly the ability to create software is becoming a core competency of companies in all industries.
With more companies leading the way and showing how Continuous Delivery and Continuous Improvement of software is possible, it is becoming a standard expectation in all industries.
In short, if your Enterprise is not investing in the ability to ship software continuously, at improving speeds, more cheaply, through more channels and target platforms at high quality, find a better place to work.
Your competitors are investing in this ability.
Where is “There”?
If we are to claim that you can’t get There from here, we need to help you understand what we mean by “There”.
Software is eating the world. Code bases are growing in size and complexity without bound. The industry and the competitive requirements around it are changing quickly. It’s not enough just to do what we’ve always done. It’s no longer competitive.
In response to some of these big changes in software, the software delivery process is being reinvented by some of the most advanced software teams in the world. Teams at companies like Netflix, Linkedin, Google and many others. These teams demand the highest degree of automation and a fast cycle of iteration that enshrines developer productivity as one of the highest goals in the company.
That’s where There is.
What we are saying is if you are under the illusion that Maven will get you There, we can definitively say to you:
You will never, ever get there from here. You will hit a brick wall at some point, and this may make the difference between your software being commercially successful or not.
Properties of a build system that will get you “There”
What we also know is that a modern build system needs to be able to simultaneously climb the expressiveness curve without sacrificing conciseness. The ability to do this is central to the design of Gradle. So Gradle has a fundamental design around being able to increase expressiveness while maintaining conciseness–this is in large part due to its build-specific domain language.
Having a deep build-specific domain language allows more and more complex and subtle expressions to be made over a domain that keeps increasing and expanding. More language platforms emerge, more developer and ops tools. More language versions appear, such as Java 9 which will include new ways to structure and modularize code (Jigsaw). The existence of this build language allows for continued evolution of the platform itself.
We have worked on some of the most complex and powerful build pipelines in the world including the one at Linkedin which generates 300,000 gradle build events per week and allows Linkedin to ship software continuously, most recently at a pace of multiple times a day and accelerating beyond that.
Working closely together with the top software development teams in the world, like LinkedIn, Netflix, Unity and Google Android, creates the best possible set of requirements to keep climbing this curve of expressiveness. And by adding new build language features we can continue to improve in conciseness. This means that Gradle itself continues to be able to evolve.
Gradle Evolution
So we have established that the requirement set for a modern build system is that optimal balance between expressiveness and conciseness, and that Gradle with it’s ever-evolving build language is ideally able to continue to grow and scale with the industry.
The good news is we can do so very quickly. Gradle as a project is itself using Continuous Delivery best practices (since we build Gradle using Gradle), and so the rate of improvement of the platform towards the ambitious needs of our high-end customers is very satisfying to see (19 feature releases in the last 3 years).
Because of this foundational design principle that preserves conciseness while allowing for ever-expanding expressiveness, Gradle will always have your back, even as your build reaches the highest levels of success and complex requirements. Build masters report as new features of Gradle come out that their builds get shorter and shorter. This reverses the trend seen in all other build platforms.
Because of this, your ability to improve both your build and to improve your software itself become possible even at extreme scales with Gradle.
Conclusion
Evaluation of Build Automation has changed dramatically because of the sheer size and scale of software projects, but also due to specific industry trends like Mobile, SaaS, Open Source, DevOps, Containerization and other trends. The industry is maturing and establishing more industrial processes for automating the software delivery process and the competitive bar is higher.
In this Age of Continuous Deployment, Build Automation Platforms should be evaluated under new criteria–the ability to power continuous improvement in both the build and the software being built. Not only should Software be continuously improved, but that platforms should be selected that anticipate the long term investment needs of Enterprises including the need for Expressiveness to meet an ever-expanding set of requirements, but at the same time Conciseness to ensure a maximum of readability, maintainability and convergence.
The myth that the previous generation can support long-term investment and can deliver continuous improvement over the coming years must be debunked. Users of these systems should migrate to modern Build Automation systems or risk hitting a wall. Software is either continuously improvable, or it is in a state of continuous decline. Choose your Build Automation platform accordingly.
The post Open Source Build System Evaluation in the Age of Continuous Delivery: Part 1 appeared first on Gradle.