Application DevelopmentBlogProduct Engineering

Why use Build Automation in Application Development?

Click To Tweet
Reading Time: 5 minutes No Comments
Why use Build Automation in Application Development Reading Time: 4 minutes
Build Automation in Devops

Growing relevance of automation & DevOps has revolutionized the software engineering industry and made a deep impact on the way traditional application development is approached. With all the hoopla around it, one thing is certain; it is here to stay with a long list of benefits.  In this blog, I take a look at why Build Automation is needed in contemporary software development projects, but before that let me quickly cover the basics and answer what exactly it is.

What is Build Automation (BA)?

BA also sometimes referred as Continuous Integration (CI), is the process of automating on-demand build creation which encompasses some or all of the below

  1. Download code from a central repository – Git, SVN, TFS etc.
  2. Make updates in code structure if needed
  3. Download required external packages via Maven, Nuget, Ant etc
  4. Build code using gcc, javac, MSBuild etc
  5. Create a building share with binary and default configuration – Jar, war, exe, XML, ini etc
  6. Propagate build output to cloud or network shares
  7. Do deployment on web servers & other servers
  8. Configure new or upgraded deployments
  9. Do BVT tests deployments
  10. Inform relevant stakeholders

A CI is triggered usually when a code commit is done or a particular tag is created. A Basic BA job is usually triggered at a fixed time; Dev teams need to finish commits by that given time.

Continuous integration Vs. Build Automation

CI’s benefit lies in giving every team member responsibility for individual commits. Faults are uncovered fast. It’s a complex process even with a licensed software or service and needs good skilled DevOps team. Despite claims of only configuration based settings, some scripting always needs to be done.

In contrast, basic BA takes the time to uncover faults but its predictable timeline reduces anxiety for Team members. It’s easy to implement leaving few manual tasks. It can be developed by anyone with basic scripting knowledge as I will demonstrate in a later post. It can be done using the native shell of an OS without any licensed software.

Hesitation about doing Build Automation

Due to the fact that basic BA may skip some manual steps, many think that it is not worth it. They aren’t helped by the lack of enthusiasm on the part of DevOps or the Dev teams. DevOps teams may think that their job is in danger.

Dev teams aren’t very enthusiastic about the need of their time. With every new technology, new ways of building code and organizing it come around. DevOps teams will not know all nitty-gritty about new build systems. Nuget.exe system may not be very clear to a DevOps person with Linux background. Git brings its own peculiarity in dealing with repositories. Dev Lead has to be really serious about helping their DevOps counterparts during automation development.

Why is hesitation not right?

Unlike CI, BA can be done economically, in less time and gives below benefits

  1. Discipline in team members – Initially, Dev teams complain about frequent build breaks but with a right push by PM, they will inculcate better habits.
  2. DevOps time-saving –They need not stay late in the night or get up early to finish daily build.
  3. QA time-saving – QA need not wait to get the new deployment before starting testing. In the case of build breaks or BVT bugs, a turnaround is faster.
  4. Management visibility – Management can uncover productivity of developers looking at build emails. Many build breaks can initiate improvement in the quality of Dev teams.
  5. Predictable clean build – Manual builds typically are incremental builds which may hide build problems.
  6. Predictable clean deployment – Manual deployments can take dependencies on deleted configuration. Automation can do fast clean installation uncovering broken settings.
  7. Wide Dissemination – More stakeholders can be kept informed by automation.
  8. Knowledge improvement for DevOps
  9. Retention Tool for DevOps – When DevOps teams are doing higher quality work, they will be more inclined to stay on and learn more.

Most benefits mentioned are for any automation project while some are unique for a BA project. It is imperative that any project with >3 developers and >3 months of development time should do BA. With the time, teams can build reusable components for BA projects.

Stakeholders in a Build Automation Project    


DevOps team must be proficient in the native shell of an OS; PowerShell, Bash etc. They can additionally learn cross platform scripting languages like Python. They need to be well versed with command line Git/SVN/TFS instead be aware of basic development methodology.


DevOps team will never know everything about a dev system. Dev manager must provide relevant help whenever needed. They also need to keep dev team members informed about requirements of build automation which may include

  1. Commit the only unit tested code
  2. Commit in time
  3. Commit with relevant messages
  4. Maintain code quality
  5. Maintain configuration file quality
  6. Use relevant naming convention in configuration files and code
  7. Help quickly in case of build breaks


QA teams are the biggest beneficiary of this exercise so they need to be very pushy upfront to get BA going. They should help DevOps with a list of BVT tests to validate test deployment and provide with reliable automation.

Project Management

BA Project must be driven by PM team. It’s an essential part of their repertoire to be aware of the challenges and modalities involved.

What’s next?

In the subsequent blog posts, I will cover different aspects of Build automation and tools using different use cases. Be on the lookout for the same and all the best for Automation projects. Do reach out to us in the case of any help needed in your process and we are sure to be a force multiplier for your requirements.