Yaz l m kalitesinin yuksek olmas , organizasyonlar aras rekabette buyuk oneme sahiptir. Teknoloji dunyas nda yasanan buyuk degisimler goz onunde bulunduruldugunda, tum bu degisimlere adapte olmak ve kaliteyi yuksek tutmak buyuk onem arz etmektedir. Gunumuz dunyas nda, yaz l m surumlerinin surekli entegrasyonu bu ihtiyac adresleyen onemli bir pratik olarak one c kmaktad r. Surekli entegrasyon ile yaz l m n derlenmesi, test edilmesi, dogrulanmas , dag t m ve kalite olcumlerinin otomatik hale getirilmesi hede enmentedir. Kalite metriklerinin olcumu ile, daha yuksek seviye kalite bilgilerinin, yaz l m n her bir surumu icin takip edilmesi; yaz l m kalitesinin art s na buyuk katk saglamaktad r. Bu surecte yasanan genel bir problem ise,olas bir kalite dusuklugunun cok gec farkedilmesi ve yaz l m s onemli miktarda kodun tekrar degistirilmesi ihtiyac n n olusmas durumundur. Bu cal sma ile, surekli entegrasyon sisteminin k sa dongulerle tetiklenmesine iliskin, yuz tan ma bazl bir yontem onerilmektedir. Bu sayede gelistiriciye erken fazlarda kalite geri bildirimi verilebilmektedir.
Face Recognition Based Small-cycle Continuous
Integration? O zen O zkaya1 ??, Hatice Erdogan1, Alphan Caml 1, Damla Gulen1, Nihat U k1, and Tamer Temizer1
A typical software development process consists of speci cation, design,
implementation, veri cation, validation, and maintenance. In literature, various
software development process models are proposed such as waterfall [
In this paper, we describe an identi cation system with face recognition method within continuous integration approach. The system identi es developer during the time spent in front of the development computer (or working desk) and when developer leaves the computer, system detects it and after a while system triggers the continuous integration pipeline including code format checking, automated building, automated testing, quality measurement and dependency reporting. After developer comes back, the system identi es developer again and presents results to developer in a well organized report format. Even the face recognition algorithm itself is not the contribution of this study, it will be explained in further sections.
The main aim with this system that is proposed in this paper is to test at the earliest feasable time and use spare time of developer instead of allocating extra time for veri cation of software. In addition to this, in the long run, we target to motivate developers not to leave from their computer with incomplete development. Because incomplete code could not be fully tested, an error report is shown about that code. Empirical results showed that by using the proposed system developers tend to leave their computer with buildable code and ready for automated integration, instead of leaving in the middle of their work and getting error noti cation about incomplete integration and veri cation results. This tendency emprically resulted to a less number of bugs in the code. 2
Philip B. Crosby who is one of the contributors of quality management has
de ned quality as conformance to requirements [
Agile methods along with continuous integration and test automation has
shown that increasing software quality without compromising cycle times and
development e ort is possible [
One of the most essential software development practices of today is the
continuous integration. Continuous integration is a well-established practice where
development team integrates their work frequently. This integration is done by
automated builds, automated tests, quality measurements, and further checks
to detect integration errors, pitfalls or drawbacks as soon as possible [
Continuous integration systems generally include quality measurement and
monitoring phase. So, measuring and monitoring software quality is as easy as
checking the integration build results which shows the quality metrics and quality
model calculations over the time [
Build frequency of continuous integration systems is a very important
parameter in practice [
As the system uses face recognition based identi cation of developer (or
tester), a real time face recognition system over webcam is developed and
deployed on each development computer. A very good feature to describe facial
features is local binary patterns [
Another complete solution on face recognition is Openface, which is a
general purpose face recognition library which relies on deep learning [
We present here our approach for providing a small cycle continuous integration system. The reason behind the need of a smaller integration cycle is that in most of the cases it becomes too late to redirect quality of the project with current integration cycle approach. Current approaches on literature mostly suggest to trigger continuous integration system once a code is released to repository. In this paper we suggest to trigger the continuous integration epoch by detecting the inexistence status of developer or tester.
System is deployed with a webcam which looks towards the face of the developer. In this process, system continuously captures the view of the developer in real time and it runs a face detection and then face recognition algorithm to identify if the developer is sitting across. No action is taken while developer is recognized by the system. Accordingly, while developer leaves the work place resulting being not recognized by the system for a while, system triggers the continuous integration process autonomously.
Once continuous integration process is triggered, system tries to build the local version of the code rstly. If the code is buildable, then artefact executables are used to run the automated tests. Even the code is buildable or not, quality metrics of the code is measured and higher level quality models are calculated by using the lower level metrics. In the next step, documentation of the code and resulting reports of continuous integration system are auto-generated.
After continuous integration epoch is completed, a summary pop-up window is shown in the screen to inform the developer about the continuous integration results, once developer comes back to the working desk and re-identi ed by the webcam based face recognition system.
In this process, developer is informed on each break and quality is measured and monitored with a smaller-cycle. On each break, developer observes where quality goes, which modules are a ected with the change and also the test results are shown if code is left buildable. In gures 1 and 2 you will nd the overall diagram of the setup for the proposed face recognition based small cycle continuous integration system.
Process ow of the described system can be summarized in gure 3.
In the study revealed in this paper, face recognition is used as person identication as it is pervasive and easy to use but surely other identi cation methods like ngerprint, retina scan or even OS login may be used for the same purpose.
Since implementing a novel face recognition algorithm is not the one of the
contributions of this study, a local binary analysis based face recognition
application is developed. As the evaluations of the face recognition
implementation resulted with %92 success ratio, it can be considered as highly succesful in
recognition for the application purpose. OpenFace framework is also evaluated
during the development but it is not preferred because of its dependencies to
side packets. It is shown that OpenFace provides near-human accuracy on the
LFW benchmark and it is always a choice for high precision recognition needs.
[
As the continuous integration platform Jenkins is used in this study as it is highly customizable, easy to use, open source and it has a signi cant amount of plug-in support. Once trigger is arrived to continuous integration server, the rst step is to check the code format. This process is done by using a formatter called "uncrustify" and comparing the properly formatted code with original code. If di erence between the les produces an empty set, then format test is assumed to be passed. Otherwise di erence le is added to format report.
The second step is to build the code. This step is usually achieved by using Make les. Once code is the compiled, other supporting artefacts like con guration les or databases are combined to deploy the system. Deployment test is a smoke test of the application which checks if vital feature like bring up works properly. Then all the automated tests including unit tests, feature tests and memory usage tests are executed and reported. If code is not buildable, then test report only includes the information of build errors and warnings.
Even code is buildable or not, code quality analysis is executed. In this step, source code is statically scanned and basic quality metrics like McCabe complexity, QMin and duplication ratio are extracted for the project modules. This metric set can be extended according to the needs. In most of the cases, a higher quality model is constructed by using the basic quality metrics. At the end, a quality report is generated which includes not only the current quality measurements but also the change of the quality with previous release.
Similar to the quality measurement step, a dependency analysis is statically analysed for the source code version and newly created (or removed) dependencies are reported.
Finally, all the reports are attached to an e-mail and sent back to developer to inform the developer about the result of continuous integration cycle.
In practice, proposed system is built for embedded software projects while it can be used for any type of software development projects. The di erence of embedded software is that codes are mostly written in C or C++ languages. Because of this fact, all the infrastructure is specially built to support C and C++ based projects.
Even it is possible to extend the quality model, in this study we used a basic quality model which will be common for both C and C++ projects. Because of these reasons, McCabe complexity, Qmin and duplication ratio are used as quality metrics.
We empirically evaluate the face recognition based small cycle continuous integration and quality monitoring approach by comparing it to traditional continuous integration approaches. Our experiments address the following research questions: { RQ1: How it is better to pick epoch cycle in continuous integration systems? { RQ2: What can be a useful trigger for continuous integration? { RQ3: What works better to intervene quality when it goes worse? { RQ4: What are the pros and cons of proposed system?
Empirical evaluation is executed for 4 project teams with 17 team members (developers) in total. Even it is hard to extract hard-numerical results, development teams made signi cant observations about the e ects of the study.All the feedbacks are collected from the team members and quality of change is tracked for 2 weeks.
The rst empirical result of the study addresses the rst research question. If too large continuous integration cycle is preferred, then it would be too late for the corrections in the system and quality. In this scenario, agility of the team decreases sharply. On the other hand, when a too small continuous integration cycle is preferred, then continuous integration overhead come o dramatically which again decreases the agility of the team as development progress is slowed down by unnecessary continuous integration attempts. Both of too small and too large epoch cycle scenarios shows that just periodical trigger management is not a good solution. Empirical results are also verifying this conclusion.
Code commit based continuous integration trigger is usually hurts quality management in continuous integration process as each commit is done after a substantial amount of code is already written. There is no doubt in this case a smaller cycle continuous integration trigger approach is needed but the problem is that continuous integration overhead should not waste developer's productive time. In this stage, second research question emerges as a better trigger approach is essentially needed. Our approach which is proposed in this paper does not waste productive time of developers as it triggers the continuous integration system basically in developer's spare time. Our empirical evaluation of face recognition based continuous integration trigger approach is an optimal solution in terms of epoch cycle as all the process is executed when developer leaves the working desk, our solution creates zero integration overhead. In this manner, solution proposed in this study perfectly solves the research problem of picking an optimal epoch cycle in continuous integration systems.
Additionally, as face recognition based existence recognition system triggers the continuous integration process on developer's spare time, it is obvious that inexistence (of developer) based trigger is an optimal solution for continuous integration triggers. This empirical result leads to a clear answer to second research question.
Our empirical evaluations also showed that, face recognition based trigger triggers the continuous integration system 9.2 times a day on average. In this process, continuous integration epoch is 52 minutes on average. This time is experimentally observed as the interval of implementation of a small software module. When developer leaves the place for a break up or a meeting, all the continuous integration pipeline is executed and reported back. As the implementation made in this interval is observed as a small software module, module's integration report is immediately reported back to developer when coming back to the desk. This optimal small cycle approach gave developer the opportunity to intervene quality when it goes worse. Hence, third research question is also answered with successful empirical outcomes. When comparing with previous month, quality measurements are boosted by %76 on average for all of the 4 projects.
As you can see from the gure 3, continuous integration system tries to build the application after code format check are done. In our empirical experiences, code is not always buildable when developer leaves the working desk. Even in this case, format checking, metric calculation over static code analysis, partial dependency analysis and related documentation is automatically executed by the system. Only run time tests and memory analysis are not done in this case as code is not left buildable, but all other steps are proceeding and developer informed with related reports.
After using the proposed system below, developers interestingly tend to left their desk with buildable code to be able to get more detailed reports and verication results of their implementation. After the rst week of evaluation, %84 of the continuous integration triggers are executed on buildable code according to Jenkins logs. This tendency created fascinating outcomes as number of bugs per code line is sharply (%42) decreased when comparing with previous months. When trying to interpret the results, an important feedback is retrieved from the developers about a di erence in their tendencies. After using the proposed system, a while, developers used to leave their desk with buildable code, it means a packed outcome of their studies and as their concentration is not broken during the block implementation, we observed fewer bugs in the projects. This outcome of the proposed system creates a huge impact on software development cycle and code quality. As each bug comes with additional development costs, our approach clearly decreases project costs while improving the quality sharply. This experiences answers the forth research question; even unbuildable code integration attempt can be seen as a con of the system, changing developer's tendencies to leave their desk with buildable code created a great positive impact.
One of the cons of the system occurs as false positive triggers. In some cases, developers sits in front of computers but does not actively write codes. Documentation or high level design tasks are good example of such cases. 6
In this process, small CI phases can as early as possible to give result. And each breaks will share CI result instead of waste of time. CI parts can be extended with developers' behaviour. Because day by day each developers will be learned to leave good, clean code as buildable, executable, runnable before giving a break. And this behaviour will get into habit of doing for developers. And with this habit CI will be more useful for software with early feed-back to developers for; improving Code Quality, developing the traceable software, unit test, etc. We can also improve small CI cycles even adding smoke Tests and getting its result too. So, we can observe the test phase, if development sends package to test, test can start or not? 7
In the software world, each day is coming with new steps and innovations. All of us who has a role in this world should catch the innovations and one step forward. And if we combine new ideas with the new features which are coming with new technologies, we can be a part of the future creation team of the software world.
In this paper, we focused on Continuous Integration part for building the automation, testing, veri cation, deployment, and quality of the software. But nowadays, analyzing the quality is only possible at the end of the CI (Continuous Integration) for each releases. In the aproach revealed in this paper is written for small CI cycles based on face detection of the developers. In each break of the developers system will be triggered with face recognition automatically for CI, and results will be shared with them when they will sit in front of the computer again.
For reaching the result in this paper face recognition method is described for triggering the CI. And it shows each break is appraisable and it can be returned with a result.