RedGage

Automated Builds



Automated builds are also required from the development team. It is
important to note that there are fundamental differences between
compiled languages (e.g. Java and C#) versus interpreted languages (e.g.
Ruby on Rails and PHP). A compiled language requires a preprocessing
step (performed by a compiler) to transform the static code into a form
executable (e.g. byte code in Java) by the runtime environment. One of
the advantages of using a compiler is that it provides an integrity
check that the code is well formed and adheres to a set of structural
rules. The compilation step often will expose flaws in the code ranging
from variable misspellings to code execution errors. While the compiler
is far from perfect to eliminating code errors, it does provide a basic
check of code quality. Interpretative languages do not require any
preprocessing step. Their code is simply processed on-the-fly (i.e.
interpreted) at runtime. The advantage of this approach is for faster
coding change cycles, and the downside is that there is not any way to
check the code for errors other than to run it.



There are implications on the build script due to language flavors –
compiled or interpreted. For compiled languages the build script must
reconcile build dependencies. For example the build provides an
opportunity to ensure that the correct application library dependencies
are present and that they are the correct version. The build script for
the interpreted language has no such check. To compensate, it is
imperative that the interpreted language perform test framework
regression tests at the time of each build. This step will ensure some
level of system integrity check. While the regression testing is also
preferred in compiled languages, it is imperative to interpreted
languages.



Software Configuration Management



When working in a team environment developing code, it is important to
have a shared common source code repository. The primary motivations of
source control are the needs to version code, provide atomic changes,
version merging and baselines and tags. Versioning code is simply a
mechanism to retain a history of the changes to code over time. Atomic
changes are all-or-nothing commits to the repository that ensures a
final state of completion once the operation is finished. Version
merging is the operation of blending together code changes from two or
more developers that have edited the same source code file. Baselines
and tags are labeling solutions to describe a snapshot of code in time,
thus allowing people to move code around as an atomic unit.



DIGS is currently using GIT. GIT is known as a distributed revision
control system. To learn more about GIT, please review the site directly
here.



Once the tollgate requirements have been satisfied and management
sign-off is acquired the quality assurance and software testing phase
may begin.