Anyone who has been around software development for awhile will have undoubtedly heard the phrase “breaking the build” at some point. What does this phrase really mean? To understand that, we need to define what a build is and how it pertains to the software development process.
A build in software development pertains to a series of steps performed on a codebase to confirm that said code compiles and is ready for deployment. While there are many tools that can be involved in these steps, the most common 2 requirements are a version control system (such as Subversion or Git) and a build server (such as Cruise Control or Teamcity). In most setups, the build server checks the version control system for changes at a set interval, and if it does detect changes it runs through its predefined build steps on the latest version of the code. This constant feedback and compilation of the latest code changes is called Continuous Integration. Building the code at every change makes sure developers do not inadvertently “break” the build and then have to dig to found out what changes caused those errors or worse, notice an error when the deadline is close as opposed to noticing it right away.
Our build process has 3 major goals. The first is verifying that the code actually compiles. This may seem trivial but it is one of the simplest things to check and also one of the easiest to catch. More often than not a developer may forget to check-in a file or 2 into the version control system and compiling the code will find that problem right away. Compiling is also a prerequisite to any of the later steps in a build as we cannot unit test code that doesn’t compile. Compiling is the only step in the build process of some companies, but we believe that quality software requires a quality build process which is where the next 2 steps come in.
The second goal of our build process is to perform our automated quality assurance testing. In our process this involves unit and integration testing, and soon it will also include acceptance testing. Unit tests test each of our individual blocks of code to make sure they can work by themselves. Integration testing makes sure that each of our “units” can work together to solve our business requirements. In this step, we also create a test database and make sure that our data access layer can save and retrieve data from a real database. Finally, acceptance tests will be performed using StoryTeller to actually open the application and run tests as if an end user were clicking through the application. By constantly testing our code we can maintain quality over time and avoid introducing new bugs in code unrelated to the latest changes.
The final goal of ProAce’s build process is packaging and deployment. In this step we create different versions of the build for our development, staging, and production environments and zip them to be deployed to each of their respective servers. Automating this step gives us the power to avoid deployment bugs related to modifying configuration files and requiring specific dependencies. We also utilize MSDeploy to automatically push the latest successful build to our development environment so our development server always runs the latest version of the application.
This was meant as an introductory post to a series of more technical posts on how our build process works. As I write each post I will update the following links:
Custom Software Development Company Application Austin, TX
A build in software development pertains to a series of steps performed on a codebase to confirm that said code compiles and is ready for deployment. While there are many tools that can be involved in these steps, the most common 2 requirements are a version control system (such as Subversion or Git) and a build server (such as Cruise Control or Teamcity). In most setups, the build server checks the version control system for changes at a set interval, and if it does detect changes it runs through its predefined build steps on the latest version of the code. This constant feedback and compilation of the latest code changes is called Continuous Integration. Building the code at every change makes sure developers do not inadvertently “break” the build and then have to dig to found out what changes caused those errors or worse, notice an error when the deadline is close as opposed to noticing it right away.
Our build process has 3 major goals. The first is verifying that the code actually compiles. This may seem trivial but it is one of the simplest things to check and also one of the easiest to catch. More often than not a developer may forget to check-in a file or 2 into the version control system and compiling the code will find that problem right away. Compiling is also a prerequisite to any of the later steps in a build as we cannot unit test code that doesn’t compile. Compiling is the only step in the build process of some companies, but we believe that quality software requires a quality build process which is where the next 2 steps come in.
The second goal of our build process is to perform our automated quality assurance testing. In our process this involves unit and integration testing, and soon it will also include acceptance testing. Unit tests test each of our individual blocks of code to make sure they can work by themselves. Integration testing makes sure that each of our “units” can work together to solve our business requirements. In this step, we also create a test database and make sure that our data access layer can save and retrieve data from a real database. Finally, acceptance tests will be performed using StoryTeller to actually open the application and run tests as if an end user were clicking through the application. By constantly testing our code we can maintain quality over time and avoid introducing new bugs in code unrelated to the latest changes.
The final goal of ProAce’s build process is packaging and deployment. In this step we create different versions of the build for our development, staging, and production environments and zip them to be deployed to each of their respective servers. Automating this step gives us the power to avoid deployment bugs related to modifying configuration files and requiring specific dependencies. We also utilize MSDeploy to automatically push the latest successful build to our development environment so our development server always runs the latest version of the application.
This was meant as an introductory post to a series of more technical posts on how our build process works. As I write each post I will update the following links:
- Building Software: Versioning and Compilation
- Building Software: Testing and Continuous Integration
- Building Software: Packaging and Deployment
