Continuous Integration (CI) Practice and Challenges, Part 1
Today, CI is given more attention than ever,
because it is becoming more and more complex to use. Large projects involve
hundreds of developers working together on a huge volume of components. As a
project scales up in size and complexity, it becomes harder and longer to
integrates all pieces together. The effort required for integrating a
system increases exponentially over time and without a Disciplined Agile Delivery (DAD), CI adoption might fail.
Taking a CI approach to software development in more complex organizations requires
scaling some of the agile practices to ensure that continuous integration
remains feasible even for a more complex project. In this blog (part 1), I
address the challenges encountered by large teams and list few tips on how to
move toward a more successful adoption.
Challenges and pitfalls to avoid
It seems so easy for organizations to lean toward
the goal of achieving CI. Some think they can reach this goal by simply buying
certain software. Wrong! CI is a practice that is supported by tools, but if
your process is broken, it cannot be fixed simply by using a software tool.
Several factors make it more challenging today
- Team size:
Larger team is likely to have more difficulties to deploy this practice.
In this situation, break the team into sub-teams which are typically
responsible for one or more subsystems and add additional roles. For
example, the overall team may require one or more people in the role of
integrator with an eye towards engaging developers and encouraging them to
adopt corporate development conventions. In order to improve collaboration
this should be enforced by some tools enabling teaming environment
- Architecture: the more complex the
architecture is, the more complex is to make several components work together. Neglecting
the architecture which identifies the major components of the system and their
interfaces is one of the pitfalls to avoid. Apply a Component-Driven integration so it becomes easier to integrate
modularized code base. DAD suggests of having an architect owner as part
of the team. The architect influence
does not end at the architecture level but it goes beyond that and may
play also the role of an integrator as discussed above.
- Frequent changes as the feedback loop is
forced and requirements change routinely. Here too, when the requirements
change on a daily basis and in an ad-hoc manner, this can be frustrating for
some developers who have already coded the feature under scope, committed the
code to the build and being asked to change it several times. Avoid making any
changes during your sprint or iteration: In DAD, you define your iteration boundaries
(usually two-four weeks) during which nothing are changed. Stick to this rule and if
any change comes outside of the scope and goals of the iteration/sprint discuss
it with the product owner, groom and re-prioritize your backlog.
- CI deployed as a standalone practice, thinking
it will do the trick without looking at the holistic view and placing it in a
context of a whole framework, including planning, testing, source code management,
collaborative, and build management frameworks). CI will expose its benefits better
if it is combined with other agile practices. For example, if you are adopting
a concurrent testing approach and refactoring regularly you are in a better
position to make your integration successful. Further, teams who adopt an
acceptance test driven development (ATDD) practice, collect feedback earlier on
the status of the acceptance tests as this reduces overhead of integration.
- Poor CI infrastructure: No shared
repositories, or not automated tooling for optimizing some of the agile
practices just as testing, source code and build management can be a drawback
for an effective integration.. Avoid multiple manual tasks which are time-consuming,
limiting the effectiveness of CI.
- Existing skills and developers mind set.
Some developers are not into the habit of sharing and co-owning the code with
other developers, and this makes it difficult to integrate. To start with the
right strategy and changing the way people work, developers need to have the
right mind set for it. This requires practice and discipline. Learning and coaching
may help in this situation.
Overall, CI is
about discipline. Ad hoc process is the major inhibitor. Following best
practices when adopting CI on larger projects will alleviate integration
issues. Keep in mind that CI needs also an appropriate infrastructure: Tools
and technologies, used wisely by enabling your process, are likely to help