Build process: A defined build process is an essential part of any development cycle because it helps close the gap

between the development, integration, test, and production environments. A build process alone will speed the migration of software from one environment to another. It also removes many issues related to compilation, classpath, or properties that cost many projects time and money. A defined process is one of the most necessary but often least-used tools in software development. It is by nature an overhead task that accompanies a development effort. A defined build process ensures that the software in your development project is built in the exact same manner each time a build is executed. As the build process becomes more complex -- for example, with EJB builds or additional tasks -- it becomes more necessary to achieve such standardization. You should establish, document, and automate the exact series of steps as much as possible. Build: If you have a large project, you often want a way to avoid recompiling everything. You want something to track what really needs to be recompiled. It is actually a little more subtle than examining the timestamps to see which files have changed since the last compile. If unchanged files use static final constants that may have changed, they too need to be recomipiled. Various tools make various brave attempts at deciding what needs to be recompiled. However, it is wise to recompile the universe from time to time in case something slipped through the cracks, especially the final build and test before shipping. Any tool for doing this in generically called a make. With Visual Studio .NET, you can easily build and compile .NET projects that contain any number of subprojects -- collections of interdependent web pages, executables, DLL assemblies, and so forth -- with a single menu command. But relying on a single programmer hitting the "compile" button doesn't always work for large and complicated projects. What if you don't care to install VS.NET on every machine you own? Wouldn't it be nice if you had a way to automate the software build process so nobody ever has to hit the compile button? There are many benefits to an automated build process, but to make it happen, you've got to have a build tool. Build tools solve problems associated with the process of compiling software. Simple software projects written by small development teams may not need a build tool -- you fire up the compiler, it builds your code into a binary executable, and you're done. But modern software is typically componentized, with each project dependent on one or more subprojects. The set of dependent components upon which your project relies may be written by many different people, who may check in different versions of their code at different times.

you want a tool that builds the external dependencies required by your application. It's common for compilers to spew forth error messages if there's something in your code that causes compiler errors. providing logs and notifications when something goes kablooey. . But in a project that is comprised of several binary executables and several more dependent components. it can throw your whole project off track.If one component fails to compile. or an out-of-date version of a component is used in a build. it may be difficult to pin down exactly where the failure took place. Developers of complex projects typically use build tools to help manage this aspect of team development. Ideally.

Sign up to vote on this title
UsefulNot useful