Virtual-Strategy Magazine – July 2, 2015
By Eyal Maor
Click here to read the article in Virtual-Strategy Magazine
The question today in the software development world is not necessarily what developers can bring to market, but how fast.
Agile and Continuous Delivery, a development approach that enables teams to produce software in short cycles with frequent releases, are becoming ever so integral and synonymous to the software-centric world. Delivering software more frequently allows companies to better offer solutions that quickly address users’ feedback. The days of infrequent releases are long gone, replaced by frequent and incremental releases, revealing that the secret sauce to Agile and Continuous Delivery is build automation.
Similar to an assembly line for a car, software development teams write and test their code in a way that resembles an automotive assembly line. Build automation has revolutionized the way software developers operate in that, similar to an assembly, it never stops and continues to move as parts are continuously added and assembled until a new product comes out of the line. Like the assembly line, build automation has revolutionized the software development industry. Car assembly lines leverage BPM (Business Process Management) and EAI (Enterprise Application Integration) solutions to automate connectivity between disparate applications, significantly reducing costs and saving time.
Using Agile and Continuous Delivery, software team members integrate their work frequently, increasing efficiency, enabling frequent releases, while improving software quality. Essentially, the Agile development process breaks down silos between development groups: testing, release, staging and development are streamlined into one continuous process, significantly increasing efficiency.
Every engineer integrates at least daily, many integrate even five times a day. According to a recent survey conducted by IncrediBuild, more than 73% of developers report running builds at least five times daily and an astonishing 22% report running over twenty builds a day. Without a build acceleration framework, this can take significant time. Integrations are verified using an automated build tool that runs regression tests to quickly detect errors. This approach enables development to work like a production line. It is fully automated, meaning that compilation, testing and many other development processes are done with no delays – one kicks off when the other finishes.
In automated unit testing for example, where each new addition to the code is made, its test can be added to the suite of tests that run when you build the integrated work. This ensures that new additions don’t break the functioning work that came before them and that the program works as expected. However, this may lead to large test suites that take substantial time to run and frequently break, necessitating frequent builds after fixing each failed test.
In order for developers to work and test together, continuous delivery requires build automation. Build automation is the task of automating many of the tasks that developers, QA, build managers, and anyone else involved in the build process do in their day-to-day activities. Build automation provides the ability to have software automatically compiled and linked into an executable and thorough test. This is where speed becomes essential.
So why the need for speed?
The need for speed is becoming ever so important now since every process is automated. If one process is broken (like a failed test), it can break the whole chain and break your build, slowing down the whole development cycle. Fast and reliable builds provide insight to resolve problems that arise in a timely fashion. That is, if an issue is found, the developer working to resolve the previous build’s conflict can test the revised code without delaying the other developers’ work. A delay in a single developer’s tasks can cause a delay in the whole chain of events, thus breaking the overall development cycle and slowing releases.
So, how do we achieve faster builds?
The build must occur continuously — kicking off a new build as soon as the previous one finishes. Successfully completing development tasks without any delay and expediting each development task as much as possible enables successful Continuous Integration and eventually contributes to the organization’s ability to succeed with Agile and Continuous Delivery.
This kind of automated build processes is very different from overnight builds or even building two or three times a day, manually configuring them to run. This method requires build automation instead of manually managing the entire build-test-deploy cycle throughout the day.
The predominant premise that “builds takes a long time” is challenged by Continuous Integration. But since any delay is highlighted, the demand for faster build time is more noticeable. Each new long lasting task can become a bottleneck to the whole build process.
With CI solutions in place now, we can better identify bottlenecks and with the insight we now have for lengthy development tasks we have advanced to a point where we look at ways to further reduce the overall build cycle. We need to look at every process and find the tasks that hold us back in our quest for a faster delivery cycles and shorten any unnecessary delay.
Accelerating those long build tasks is the next step in achieving faster Continuous Integration cycles. One way to achieve faster build tasks is to execute them in parallel, thus speeding up the overall build time. Since all computers today have more than one CPU, it is possible to utilize all of them to execute those tasks in parallel. In order to scale multi-process execution you can also use solutions such as IncrediBuild. This enables developers to not only run build tasks locally, but also harness unutilized CPUs in the local network or use public cloud resources to add more CPUs and memory on demand, further accelerating build tasks and greatly reducing your development cycles.
Cellebrite, a leader in mobile forensics, had portions of their code spanning hundreds of individual projects. They looked to reduce their gated check-in process from 5-6 minutes to around 1 minute. While in the past, a single product release for all its customers would take hours, today the company can issue a complete release cycle in less than an hour. Furthermore, the new corporate standard is that a single developer can check-in code and receive a testable installation package in no more than 10 minutes. This has led to a major shift in the way developers and QA engineers view their own build processes. Before implementing IncrediBuild, a full rebuild took 16-17 minutes – a real hindrance to Continuous Integration. After implementation of IncrediBuild, full rebuilds were reduced to 6 minutes, with incremental builds taking only 60 seconds. This acceleration really put the continuous back in Continuous Integration.
If we used to look at overall build time and tried to shorten it, we can now look at each and every process executed during the development lifecycle within each CI cycle and try to see how we can shorten each step and each associated task, so developers and testers alike will not move to new tasks just to find out later that their previous build is broken.
Agile methodologies drive Continuous Delivery practices to evolve and look for new ways to make the processes faster. Build managers and DevOps practitioners don’t have to accept any process time as if it is the best they can achieve. Finding new ways to accelerate the CI execution will enable you to save time and improve your organization’s ability to better respond to business demands and contribute to your Continuous Delivery objectives.
Eyal Maor is CEO of IncrediBuild, a leading provider of software acceleration technology.