Shulou(Shulou.com)06/02 Report--

This article mainly explains "what is Travis CI". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is Travis CI".

Travis CI was just an idea at first, and it was even idealistic at the time. Prior to the launch of the project, the open source community did not have a continuous integration system available.

With the increasing recognition of Github as an open source collaboration platform, Github also needs services that can continuously test the contributing code to ensure that an open source project is always in a stable and healthy state.

Travis CI started in early 2011 and quickly got some trial customers. By the summer of 2011, we were building 700 times a day. All of these builds are done on a single build server. Travis CI is integrated with Github***, and Github is currently the main platform of Travis CI.

Travis CI doesn't have an earth-shaking move in the field of continuous integration, but it does redefine some old concepts and add some new ideas. One of them is that you can see the build log flow of the project in near real time during your test run.

Most importantly, Travis CI allows you to configure the build process through files (.travis.yml) in the source code, rather than a complex user interface.

Travis CI started out with a simple architecture. The Web component makes the project and its build process visible, and as soon as a new commit is submitted to the project, the Travis CI receives a message from the Github, triggering the build.

Another component, called hub, is responsible for processing new commits, converting them into a build, and processing the resulting data when the build task runs and ends.

Both components deal with PostgreSQL databases.

The third part is the collection of threads that control the build task itself, which can be used to execute a series of commands on the virtual machine instance.

In essence, hub appears to be a little more complex than the rest. When hub processes the build log, it needs to message with RabbitMQ. The log is obtained as a chunks stream from the thread that controls the build task.

Hub updates the log and build result information in the database, and hub pushes them to Pusher. Pusher,Travis CI allows you to update the user interface at the beginning or end of the build.

This architecture lasted until 2012, when we did 7000 build tasks a day. We are pleased to see that Travis CI is becoming more and more widely used in the open source community and is beginning to support 11 languages, including PHP,Python,Perl,Java and Erlang.

With more and more use, Travis CI becomes more and more like a must-have service for an open source project. Unfortunately, monitoring was not considered when the system was built in the first place.

In the past, users from the community always informed us that the system was not working properly, that the build task encountered an exception, or that the task information was not handled properly.

That's embarrassing. Our challenge is to add monitoring, data metrics and logs to the system to transform Travis CI from a business hobby project into an important business platform. We are going to release the official production version of Travis CI.

Being told by users that the system is not working properly is still a nightmare for me today, and we have to work hard to build data monitoring so that the system can notify the system as soon as something goes wrong.

Without any data records or good logs, it would be impossible for us to figure out what happened to our small distributed system. Either way, Travis CI is already a distributed system.

Adding monitoring metrics and logs is a step-by-step learning process, but in the end, they allow us to understand what the system is doing, whether through charts or logs.

This is a huge improvement for us. Visibility is very important for running a distributed system.

When you write a system, think about how to monitor it.

Good monitoring will help your system run better in the production environment, not just pass the test.

The point is, more monitoring will not only give you a better understanding of the system, but you will also find problems that you have never thought of or seen before. Higher visibility of the system leads to a greater sense of responsibility. Now we need to face the fact that we know more about system errors, so we must work more effectively to reduce the impact of these errors.

Thank you for your reading, the above is the content of "what is Travis CI", after the study of this article, I believe you have a deeper understanding of what Travis CI is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.