During the integration builds, all of the newly completed
tasks from developers are gathered and built. They are gathered based
on the integration testing process rule that is used by the integration
testing project hierarchy.
About this task
Here is what is included in the integration
test cycle:
The software is likely to have problems during
the integration test cycle, and might not build successfully. The
goal is to find problems right away, not to get a high-quality installation
area. Stability is not the goal right now because of the unstable
nature of the software in the development cycle.
Here
are some of the types of problems you might see during integration-level
builds include:
- Parallel branches that have not been merged (you
get changes from one developer, but not from another developer)
- A developer checked in part of the changes, for
example, a developer forgot to associate all necessary objects to
complete a particular task.
- Two developers made incompatible changes, for example,
they both added defines with the same name.
- A program fails to compile because of syntax errors,
for example, the developer forgot to unit test.
The integration build area is not a stable
environment because it contains the most recently completed tasks.
Another reason is that the candidates change frequently as developers
complete their tasks. This instability is normal.
The
integration test cycle is short and frequent, which helps you to find
problems as early in the development cycle as possible. Additionally,
developers with insulated development projects do not bring in each
outside change until the tasks have passed integration testing.
The integration cycle works best if you
can build and test every day. Make the newly tested tasks available
to developers immediately after they pass testing.
Typically,
here is what is included in the integration-level build cycle:
- Developers continuously change objects and check them in by completing
their tasks, without regard to the cycle. (The advantage is that the
team is not interrupted or distracted by testing efforts.)
- The build manager updates, shows conflicts, resolves conflicts,
builds the hierarchy, and creates an installation area or media to
be tested. (Part of this process can be automated and done as a nightly
job.)
- The build manager tests the resulting products with a short set
of tests that verify that the product builds correctly and is usable.
If defects are found, a member of the team creates tasks to fix the
problems.
- If no severe defects are found, the application is ready for use,
for example, as a development test area. This cycle might not happen
every day. On days when severe defects are found, the build might
not succeed.
- If the build manager finds no severe defects, the process continues
with Creating a baseline.
The baseline makes the objects that are associated with the tasks
in the baseline available to developers the next time they update
their projects.
Now that you understand the tasks to complete during the integration
test cycle and why you must complete these operations, you are ready
to perform the operations.