

“At Semaphore we take performance very seriously and our CI/CD platform is based on dedicated hardware with desktop-class performance. I reached out to the co-founder of Semaphore CI, Marko Anastasov, to see if he could explain these differences and here is what he had to say: Nearly two minutes were shaved off of our builds on average with the default Semaphore test settings! That’s pretty impressive by any standard. The mean build times were 208.6 seconds (+/- 16.7s) on Semaphore and 319.4 seconds (+/- 33.6s ) on Travis. There was a statistically significant (p<0.05) decrease in build time across these five recent commits that amounted to a mean 110.8 seconds saved on the Semaphore CI service. Mean (+/- SD) for build times across five commits to the Hack typeface repository for Semaphore (blue) and Travis (red). The git commits are labeled with git commit SHA1 short hash strings on the y-axis. The following figure demonstrates the raw build time in seconds by git commit to the Hack typeface repository.

The builds were run on both testing services simultaneously via GitHub git commit hooks.
#SEMAPHOR GOOGLEDOCS SOFTWARE#
These data exclude queue time and represent the software build testing execution time only. Here are the data on the build execution times required for five recent sequential commits in our repository. The Python versions were 2.7.13 on Travis and 3.6.x on Semaphore. The gcc versions were 4.8.4 on Travis and 4.9 on Semaphore.

The git versions were 2.13.0 on Travis and 2.14.2 on Semaphore. The Travis and Semaphore tests were both performed on Ubuntu 14.04 LTS systems. The time-intensive tests for us are those shown in the list above. We perform parallel shell script linting tests that are not considered in this analysis as they are brief relative to our compile tests and do not impact the total time to test completion. This build process has historically required approximately 4–5 minutes on the Travis platform.

#SEMAPHOR GOOGLEDOCS FULL#
#SEMAPHOR GOOGLEDOCS SERIES#
The build process involves the following series of steps: The following analysis compares the two testing services with the same git commits that were pushed to the Hack typeface repository and built simultaneously on both CI testing platforms via GitHub git commit hooks. Intriguing! As a long time user of Travis CI, I decided to put the test services to the test and find out if these benefits apply to our software testing needs.
