Why Build Platforms Evolve: From Manual Scripts to Cloud‑Native Automation

1 Origin of the Build Platform

Software development inevitably involves building, which bridges source code and the runtime environment. Build is not the same as compile; it translates source code, configuration files, and resources into artifacts that can run on physical machines, virtual machines, or mobile devices.

Automating builds became essential for productivity, leading to the creation of a "packaging platform" that automates repetitive tasks.

Automated builds address basic needs, while CI/CD platforms handle higher‑level productivity demands.

2 Understanding Build

Build is a complex orchestration process, not just compilation. Two examples illustrate this:

Android APK Build Process

The green part represents tools, the light‑blue part represents source code and intermediate products. The sequence of tools and inputs produces an APK that Android devices can run.

Java JAR Build Process

Building a JAR is simpler but still requires a series of coordinated steps.

Build Tools

Manual commands like javac, copy, jar become tedious as projects grow, prompting the development of build tools.

Ant

<?xml version="1.0" encoding="UTF-8"?>
<project name="HelloWorld" default="run" basedir=".">
  <property name="src" value="src"/>
  <property name="dest" value="classes"/>
  <property name="jarfile" value="hello.jar"/>
  <target name="init">
    <mkdir dir="${dest}"/>
  </target>
  <target name="compile" depends="init">
    <javac srcdir="${src}" destdir="${dest}"/>
  </target>
  <target name="build" depends="compile">
    <jar jarfile="${jarfile}" basedir="${dest}"/>
  </target>
  <target name="test" depends="build">
    <java classname="test.ant.HelloWorld" classpath="${hello_jar}"/>
  </target>
  <target name="clean">
    <delete dir="${dest}"/>
    <delete file="${hello_jar}"/>
  </target>
</project>

Ant defines tasks such as init, compile, build, test, and clean. Dependencies are expressed via the depends attribute, e.g., ant test runs init → compile → build → test.

Ant lacks dependency management, requiring developers to manually copy correct library versions.

Maven

Maven extends Ant by adding dependency management, a central repository, and a convention‑over‑configuration lifecycle. Projects are described by pom.xml instead of build.xml.

Gradle

Gradle replaces XML configuration with a Groovy DSL, inherits Maven’s repository concepts, and retains Ant‑style tasks (now called task). It offers a more concise syntax, e.g.:

dependencies {
    compile('org.springframework:spring-core:2.5.6')
    compile('org.springframework:spring-beans:2.5.6')
    compile('org.springframework:spring-context:2.5.6')
    compile('com.google.code.kaptcha:kaptcha:2.3:jdk15')
    testCompile('junit:junit:4.7')
}

Gradle reduces a typical Maven configuration from 28 lines to 7 and provides incremental builds, build cache, and daemon for faster performance.

3 Evolution of the Build Platform

1 Raw Era

Initially, builds were manual, with a single developer compiling on a personal machine for mobile apps or a single physical server for backend services.

2 Automation

Growth required project management, multi‑person collaboration, and automated builds, leading to the emergence of CP (project management) and SCM (code management and build scheduling) platforms.

3 Containerization

Docker introduced lightweight, isolated environments, enabling builds to run in containers, simplifying environment consistency and scaling.

Docker’s limitations (single‑stage cache inefficiency, inability to parallelize multi‑stage builds) motivated the adoption of buildkit and Kubernetes.

4 Image‑Based Builds

Beyond containerization, image builds became critical for ensuring runtime environment consistency across machines.

5 Embracing Cloud‑Native

With increasing serverless adoption, cloud‑native CI/CD on Kubernetes (e.g., Tekton) became essential. Tekton, a CNCF project, provides reusable CI/CD components tightly integrated with K8s.

Jenkins X is committing fully to Tekton as its pipeline execution engine.

Ant Fin’s internal platform “ironman” runs tens of thousands of builds daily using Tekton.

6 Challenges and Future Directions

Key challenges include maintaining environment consistency, handling diverse build scripts, supporting multiple OSes (Linux, Windows, macOS), and avoiding resource fragmentation.

Future goals:

Make build logic fully describable and version‑controlled.

Enable dynamic insertion and removal of build resources (K8s, Jenkins, physical machines).

Example of a declarative build specification ( buildspec.yaml) that can run on any supported resource:

name: android-aar-build
params:
  - name: productLine
    default: alipay
  - name: sprintId
    default: ${SPRINT_ID}
resources:
  - name: code-repo
    type: git
    url: https://code.alipay.com/xxxxx
    ref: master
environment:
  type: LINUX_CONTAINER
  image: reg.docker.alibaba-inc.com/alipay/aarbuild:latest
buildTasks:
  - name: Download config
    image: python:3
    commands:
      - python --version
  - name: Install Dependency
    image: ruby:2.6
    commands:
      - echo "-------2 in ruby:2.6"
      - ruby -v
artifacts:
  - name: pod-for-alipay
    type: iot-sign
    path: xxxx.zip

By describing builds in this way, Ant Fin can flexibly route jobs to Kubernetes, Jenkins, or physical machines, achieving high availability and scalability.

7 Recruitment & Resources

Ant Fin is hiring engineers to build the next generation cloud‑native development platform. Interested candidates can email [email protected].

Free e‑book “Cloud‑Native Large‑Scale Application Guide” is available for download.