Having a build server in place is almost essential nowadays in the software development industry. It represents the current state in the process of evolution of delivering softwares. We have been talking about Continuous Integration and Continuous Deployment since more than a decade now. But we still question - do we really need a separate build server? Does it make sense to have one in place?
It absolutely does. Developing a software product is not just about coding. There are several non-code aspects associated with it. In fact these are those aspects which some of the best coders dread about. Versioning and packaging the application, making it operations ready, making it pass Quality gates, making sure it follows certain rules laid down by CI/CD process for easy tracking of issues and features etc are some of those things.
Build servers ease this process by giving software development a central and first place to release the first usable bundle. We know, every IDE comes with a Run/Build button and it is a matter of a single click which can be done locally by every developer, then why bother having a dedicated server to just do builds?
Local builds have several drawbacks and are the main reasons for “It works on my machine” syndrome. Build servers are neutral machines which try to build and test your code in the sense, they do the clean build of the code every time you push new code to the repo. Build servers typically fetch the code from version control systems and build it. They run automated unit tests and generate feedback. If the code is clean (testing is successful) they create an application package - which is the deliverable for toolchain and if you configure it right, it may also be able to promote your application through environments.
Basically, you let your computer take care of building and deploying your package because they will do it the same way every time. Thus, automation is the key - the more you do it, better will be the delivery.