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 involvehundreds of developers working together on a huge volume of components. As aproject scales up in size and complexity, it becomes harder and longer tointegrates all pieces together. The effort required for integrating asystem 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 requiresscaling some of the agile practices to ensure that continuous integrationremains feasible even for a more complex project. In this blog (part 1), Iaddress the challenges encountered by large teams and list few tips on how tomove toward a more successful adoption.
Challenges and pitfalls to avoid
It seems so easy for organizations to lean towardthe goal of achieving CI. Some think they can reach this goal by simply buyingcertain software. Wrong! CI is a practice that is supported by tools, but ifyour 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 thearchitecture is, the more complex is to make several components work together. Neglectingthe architecture which identifies the major components of the system and theirinterfaces is one of the pitfalls to avoid. Apply a Component-Driven integration so it becomes easier to integratemodularized code base. DAD suggests of having an architect owner as partof the team. The architect influencedoes not end at the architecture level but it goes beyond that and mayplay also the role of an integrator as discussed above.
Frequent changes as the feedback loop isforced and requirements change routinely. Here too, when the requirementschange on a daily basis and in an ad-hoc manner, this can be frustrating forsome developers who have already coded the feature under scope, committed thecode to the build and being asked to change it several times. Avoid making anychanges 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 ifany change comes outside of the scope and goals of the iteration/sprint discussit with the product owner, groom and re-prioritize your backlog.
CI deployed as a standalone practice, thinkingit will do the trick without looking at the holistic view and placing it in acontext of a whole framework, including planning, testing, source code management,collaborative, and build management frameworks). CI will expose its benefits betterif it is combined with other agile practices. For example, if you are adoptinga concurrent testing approach and refactoring regularly you are in a betterposition to make your integration successful. Further, teams who adopt anacceptance test driven development (ATDD) practice, collect feedback earlier onthe status of the acceptance tests as this reduces overhead of integration.
Poor CI infrastructure: No sharedrepositories, or not automated tooling for optimizing some of the agilepractices just as testing, source code and build management can be a drawbackfor 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 withother developers, and this makes it difficult to integrate. To start with theright strategy and changing the way people work, developers need to have theright mind set for it. This requires practice and discipline. Learning and coachingmay help in this situation.
Overall, CI isabout discipline. Ad hoc process is the major inhibitor. Following bestpractices when adopting CI on larger projects will alleviate integrationissues. Keep in mind that CI needs also an appropriate infrastructure: Toolsand technologies, used wisely by enabling your process, are likely to helpdrive success.