Software Build Best Practices in Software Configuration Management

Folks, in our last article we discussed about the software build process. The build process may vary from organization to organization based on their implementation and technology used.

Whether they are following the build process in correct manner or not – is a different question.

Missing out a simple step can lead to big trouble where you need to investigate and dedicate days and days to find out one small mistake which could have been easily avoided if SCM process was followed correctly.

Lets take an example, a developer “Dan” just created a build manually on his machine and didn’t archive any build before.

The build was also created without his colleague’s code as the other developer hadn’t committed the changes in source repository.

Dan also deployed the code in production but later realized that the build was improper.

Dan then started looking for the previous build at all the places, searching in the build log, trying to find out what and where it was missed, etc.

Now the trouble begins…

It could be a very simple activity if Dan would have followed the build best practices.

So, here we are with our latest article on software build best practices in SCM.

#1. Have a dedicated Build Server

The reason why we need a build server is pretty simple. In an organization which doesn’t have a dedicated build server we often hear below statements on failure/errors.

• It works on my machine, there must be some problem with your machine
• I don’t know why this test has failed on your machine whereas same code is working on mine
• Ohh, you are using different version of source code and that’s the reason its not working

If you can’t afford a dedicated build machine then developers will always run the build on their machine followed by deploying the same build into target server which will create errors after build.

This can mean an out-of-sync check-ins or it could mean a dependent library is missing or any missing linked file etc.

I’m not saying that developers should not build code on their machine at all.

They can, but that build should be just for testing purpose whether the module developer has built is working or not.

They should not use the same build on target deployment server instead they should use the dedicated build server to build the code to avoid any issue.

When developers use build server to fetch the code from version control system and build code by following proper build process,then build’s packages are reproducible and more traceable.

Developers who manually build code on their machine for anything except their own testing can be a high risk to the project.

The Build Server is a machine with pretty good server configuration which can handle a high throughput and multiple tasks.

This server should have all the required packages/software installed in order to build the code and produce build artifacts.

All the software installed should be approved and there should not be single bit present on the server which is unknown to the SCM/project team.

This will help in making it possible to flag issues and notify developers as quickly as possible if there are conflicts or missing dependencies.

It also ensures that the same dynamic link library is used for all builds and those out of sync check-ins doesn’t cause failure during testing.

Build server is a machine which will help in reducing developer’s machine load and storage by fetching out the code and building it as per the requirement and process.

In this new world of distributed development environment where multiple developers are working on the same code base, the developers may not often interact with each others code.

The build server acts as a central system where all developer’s code can be built and developers can be notified about any issue.

Now, rather than asking developers to create builds on their machine and worrying about merging code every time which may create issues, we should design the build process where the automated build server can see the appropriate code and processes the build artifacts in a predictable way which not just increase the productivity but also ensures that the build is appropriate and correct every time.

#2. Build Early and Build Often

This approach proves to produce faster development and it helps a development team to identify the issues which may arise due to syntax error, checking in wrong code, missing library, compatibility issue, etc.

This approach is also useful to find out the issues at an application level that might have slipped passed in individual developer builds.

#3. Automate the Build Process

This is the most important piece in build life-cycle. This will help in predicting the accurate build results and assure that there would be very minimal development down time due to build issues.

This also ensures that the build process is completely repeatable and consistent which will increase the productivity.

Build Automation is a process to combine all the necessary build activities starting from checking out the correct source control code to compile, running the test case and then creating a build artifact after linking the libraries and relative files.

Automated builds have become a keystone of agile development. Every time a developer checks in a change, the automated build process checks out all the sources, builds everything, runs all the unit tests and reports back with immediate feedback.

#4. Archive the build logs

Always create and keep the build logs for further use and for investigation in case of any error/issue.

This will help you in many ways, like finding out the error in build failure, checking the status of automated tests, verifying whether all the build related files were fetched out or not, for audit purpose, etc

#5. Configure and use Artifact Repository

An artifact binary repository will be used for storing all the build artifacts at one single place.

It will help you to manage the binary artifacts and associated metadata. It also provides the audibility and tractability for all the builds and their resultant artifacts.

#6. Commit/Check-in all the program/build related files prior triggering the build

All the developers should follow this process to create a successful build.

Developers should make sure that their commit will not break any functionality and create any issue on target server.

Before committing the code in source control repository, the Unit tests must pass in the local developer’s environment. If the unit tests are failed, the developer must resolve the failure prior to check-in the code

#7. Choose and configure the best build tools

To make a efficient and stable project, always take an extra time for choosing and implementing the best tool for Build.

It will also ensure the build number is incrementally changed for each build which will helps you to find out what has happened with any particular build.

A dedicated build server with good server specs and hardware always resultant to a quick and stable outcomes.

#8. VCS for build scripts

Always use the Version Control Systems for all the build scripts to ensure you don’t loose any script or information in case of server failure or any other issue.

#9. Send the notification mails

It is a good practice to inform all the team members who are working on the project about the build status, either in case of build failure or success.

This will help all the project members to get the current status of their project, they can also use the notification mails to initiate the conversation about the build failure, etc.

So, here I have tried to compile an exhaustive list of best practices to follow for Continuous Integration/Software Build process.

Hope you enjoyed reading about these best practices – are there any build best practices which you follow and are missing on this list?

Do inbox us here and I will be happy to add them to this list

In our next article, I’ll write about the software build tools.

Till then, stay tuned!