Continuous Integration and Software Builds-
OpenMake Meister and OpenMake Mojo provide an enterprise level continuous integration build server allowing for build loops to be triggered by an SCM Check-in Process with full workflow and build management processing. OpenMake Mojo can be downloaded for Free and will support both CI and Application Life Cycle workflow processing. Both Meister and Mojo integrate with best of breed and open source application life cycle tools for easy out of the box workflow definition and execution. OpenMake Meister enhances the Continuous Integration build process by accelerating your software compile and link processes. Meister does not stop at automating the pre and post steps around the compile and link process. Meister also drives down into the calls to the compilers and linkers themselves. By improving and automating the compile and link steps (the build itself) Meister can improve your Continuous Integration processing times by as much as 50% for full builds and less than 10 minutes for incremental build. Meister allows you to develop a compile and link process that can keep up with the pace of your agile check-in and build methods supporting all languages including Java, .Net, Eclipse, IBM RAD, C, C#, C++ and more.
What is Continuous Integration? The term “continuous integration” has been unfortunately overused. As a result, the original intent of a continuous integration build process has been reduced down to the ability to manage an application lifecycle workflow like a job scheduler. Job scheduling does not improve a developer’s ability to speed up compile and links, reduce redundant compile and link steps, or sort out dependencies for analysis and build avoidance. These topics have been lost in the marketing spin and buzz around a continuous integration server’s ability to call a particular test or email process. Let us be clear, workflow processing is useful, but it simply does not go far enough to support a complete continuous integration process. Build automation is what agile developers need to complete the picture. The original purpose of a continuous integration process was all about immediate feedback and the ability to speed up the compile and link process for the single purpose of decreasing integration times. This feedback is established via the “build-loop.” A developer makes a source code update and then needs to compile and test the update against the changes that other developers are making to dependent source modules. The continuous integration server would execute pre-written compile and link scripts as new source is added to the repository. In other words, the most important function of the continuous integration server is all about automating the conversion of source code into binaries as quickly as possible so developers get information they need to continue working. Many heroic developers manage the build scripts running on the continuous integration server allowing the rest of us some level of build “oblivion.” We just want the build to work. We also want the build to be fast and for any post activities of the build, like testing to be executed once the build is done. This is what workflow does. But workflow does not do the heavy lifting of getting the binaries created. The hero developer who is maintaining the scripts performs this function. The Build automation is all about improving the way source code is converted into binaries during the continuous integration build. Build automation is the power tool that the heroic developer needs to streamline the calling of compilers and linkers. Build scripts get one thing done, they create a deployable object. What build scripts can’t do is automatically update themselves because source code changes impacted the way the build executes. The hero must discover and fix this. Build scripts cannot speed up a build by sorting out dependencies and building multiple objects at the same time. If this is needed, the hero must create sub-scripts and farm out the process using the workflow capabilities of the continuous integration server. Build scripts cannot automatically determine what files are up to date and re-build only the changes. Again, this functionality must be written into the scripts, and some scripted solutions do not offer easy methods of sorting this out. Build automation extends the functionality of the compile and link process to support - Delivers fast builds via build avoidance or parallelization.
- Minimizes or eliminates bad builds.
- Supports frequent builds (compile/link) for improved “feed back” loops.
- Provides dependency and impact data and analysis.
- Automatically synchronizes IDE builds to the continuous integration build.
Agile developers are pushing the envelope when it comes to managing changes more frequently, demanding that builds (compile and links) run faster and more consistently. There are many solutions that claim to improve “builds” but most only offer ways to call a build script from a scheduled or triggered workflow process. Build automation goes beyond simple workflow management and provides the hard core solutions for improving the consistency, repeatability and speed of the compile and link process. A new breed of build management tools is available for addressing the core of the continuous integration process – the build itself. However, it can be difficult to sort through the marketing spin in order to understand which tool does what. Pre-Commit or Pre-Flight Builds
Build automation also supports the continuous integration pre-commit or pre-flight build. This build is used to validate that a source code change will not break the team continuous integration build. A pre-commit build is performed in a private area against the continuous integration branch of code. Pre-commit builds are only useful if they can be preformed in record time and should not be executed in a "clean all" mode. Pre-commit builds should run in an incremental mode, re-building only those items that have been impacted by the change. Pre-commit builds that run in a "clean all" mode, re-builds all objects. When a complete re-build is performed, the build can run for extended periods, reducing the effectiveness of the pre-flight build. In other words, if a pre-flight build takes 2 hours to execute, it will not guarantee that when the source code is finally checked into the version repository and a continuous integration build executes, that the continuous builds will not break. Continuous Integration Feature | | | Snychronizes the IDE Build with the Build executing outside the IDE on the Continuous Ingtegration Server | √ | | Improves buid speeds using Build Avoidance and parallelization | √ | | Pre-Commit (Pre-flight) Builds with incremental build processing (Build Avoidance)
| √ | | Dynamic Continuous Integration Build Scripts for Adaptable builds | √ | | Eliminates build redundancy | √ | | Enables Continuous Integration build loops | √ | √ | Supports Application Lifecycle Plug-ins | √ | √ | Centralizes Build Logs and execution | √ | √ | Schedules Builds | √ | √ | Real-Time Build Monitoring | √ | √ | Supports standard Build Scripts such as Maven, Ant, Nant or Make | √ | √ | Integrate with Software Configuration Management Systems (Dimensions, PVCS, VSS, Clear Case, CVS, Perforce, StarTeam, Razor, SubVersion, SCLM, STMS, DPF, etc.) | √ | √ | Eclipse Plug-in support | √ | √ | Supports chaining of build steps to define step dependencies | √ | √ | Centralized build monitoring for cross platforms and cross languages | √ | √ |
|
