Continuous integration systems are responsible for the building and testing of applications in a context where it takes a long time. Developers do unit tests, which should take a few seconds maximum, in their development machines, but delegate the integration tests, which may take several hours, to a dedicated server. Additionally, the continuous integration server can automatically build the application to different platforms and test it, for example to test an Android application in different device simulators.
The architecturally significant requirements are: ease of configuration, interoperability with software development tools, and manageability in the execution of builds.
Ease of configuration is achieve by two kind of interrelated scenarios: usability scenarios where developers can easily configure a particular build, and modifiability scenarios that allows the change of the modules that will take part in a particular build. The Jenkins system supports the former by providing user interfaces that contain a task model which reduce the number of errors during configuration, and the latter by a rich set of plugins that can assembled during the build construction.
The interoperability with software development tools is based on adapters and standards that support the communication with external tools, like for instance the GitHub Plugin to checkout the code from the GitHub repository, and externalize the results to be used by other tools, for instance through the use of JUnit XML.
Two different software architectures deal with the manageability architectural requirement. The master/slave architecture ofBuildbot emphazises the schedule resources tactic, where the master is a coordinator of the build process in the slave servers. This architecture allows a complete control of the build process, the observation of intermediary results, and the more efficient use of resources, which improves the overall performance of the build. However, the master is a single point of failure, reducing the availability of the system. On the other hand, CDash centralizes the collection and aggregation of results in a central server, the dashboard, to where the clients, which actually execute the build, send their results using a XML format. This architecture provides a less efficient execution of builds, due to the lack of a central coordinator, but is more scalable, as clients are completely independent. However, it may have some negative impact on security, because the Dashboard component has to trust in the client components.