Hope you remember our very first article about SCM where we discussed about software configuration management which comprises of several activities.
Build is one of the important and mandatory activity among all.
So, till date we have discussed about SCM and VCS, now suppose you did your own investigation/research and found out the best suitable Version control system, you have then configured it accordingly and created the repositories for your project as well.
The next step now is to write the code, commit and build it through build tools.
So, lets discuss the concepts, facts and process of Software Build.
Software Build in simpler term is an activity to translate the human-readable source code into the efficient executable program.
Basically, Build is the process of creating the application program for a software release, by taking all the relevant source code files and compiling them and then creating a build artifacts, such as binaries or executable program, etc.
You can also say that the build process is a combination of several activities which varies for each programming language and for each operating system but please remember the basic concepts are universal.
Now, lets consider an organization where the project team got a detail about the work which they have to deliver after sometime.
The Project manager discusses the requirement with their dev team lead(s), the leads then decide whom they need to assign different module so that whole program can be built in sufficient time.
Once developers are assigned the task to write a code for the given requirement, all the assigned developers will write the small modules of the program.
As soon they finish writing the code and run the tests on their local machine, they can either integrate the code with main version control repository so that all the work done by all the developers can be build in single build or they try to build the code on his/her own machine to test their module functionality.
What is Build Process?
The build process consists of following:
- Fetching the code from the source control repository
- Compile the code and check the dependencies/modules
- Run the automated unit tests
- Link the libraries, code, files, etc accordingly.
- Once successfully passed, Build the artifacts and store them.
- Archive the build logs.
- Send the notification mails.
One of the important factor of the build process is their types and the way how often people using them.
So, lets talk about the Build Types!
Ideally there are two basic types of builds.
A full build which performs a build from scratch. It treats all resources in a project as if they have never been seen by the build server/tool.
A full build always starts from empty work area; its taking a full project as a input, figures out the dependencies, compiles all the source files in your project and builds all the parts in order accordingly, and then assembles them into the build artifact as a final output.
An incremental build which uses a “last build state,” maintained internally by the build server/tool, to do an optimized build based on the changes in the project since the last build.
An incremental build checks and compares every source file, as well as anything else that depends on the target, if any dependency has been modified after the target was last built, the target will be rebuilt, otherwise the file from the previous build would be reused.
Since incremental builds only rebuild what needs to be, they are usually much faster than full builds and use fewer resources.
Moving further, when we talk about the build, there should be some way to initiate the build. Yes that way is known as Build Triggers.
There are several approaches/methods for triggering the build. Some people name this term differently but the concept is same.
Software Builds: Important Terms
Below are the most usable terms in field of software builds (please note that all terms mentioned below triggers either full or incremental build based on the requirement and build configuration).
Manual build trigger: This is the most common build trigger. Whenever you are ready with the code/change, you can go to the build server using build tool and trigger the build.
Scheduled build trigger: Scheduled build triggers are configured to run the build at specific time of the day or when a specific event occurs.
This triggers can be configured to force builds regardless of whether source changes occurred. One of the best example of it is scheduled nightly full build.
Source code repository build trigger: This trigger initiates builds whenever any source code change occurs in the repository.
When a developer commits any change in the version control system, this trigger gets initiated.
It can be customized whether you want to trigger a build when a any single file get changed or any specific file(s) get modified/checked-in.
Post-Process build trigger : Post-processing build triggers listen for post-processing events.
When an event is detected, it can trigger other events or any upstream/downstream build.
Hope you got an idea about the build process and about its importance. I’ll continue this journey with build best practice and with build tools in coming days.
See you again!
Till, then don’t stop your quest for SCM 🙂