Author:
- Thom Ellis - Mentor Graphics
Abstract:
The topic of Continuous Integration (CI) is one which has started to become more and more common in the world of verification. For those unfamiliar with CI, it is a concept often associated with Agile programming practices, and it runs off the basic principle that the longer a branch of code is checked out, the more it begins to drift away from what is stored in the repository. The more the two diverge, the more complicated it becomes to eventually merge in changes easily. Ultimately leading to what is commonly referred to as "integration hell". To avoid this, and ultimately save engineers time, CI calls for integrating regularly and often (typically daily).
Regular check-ins are of course, only half the equation, you need to be able to verify their changes quickly as well, otherwise many small check ins over several days, is no different than one large check in at weeks end. Commonly, in a Continuous Integration environment, a CI server monitors the source control for check in's, which in turn triggers a CI process (time-based triggers are also common). This process will then build the necessary design files, and run the requisite integration tests. Once complete, the results of the tests are reported back to the user, and assuming everything passed, can now be safely committed to the repository.
By following this model, issues can be caught earlier in the development process, and can be resolved quicker as there is less variance between check ins.
There are several options to choose from when it comes to CI, however, far and away the most common solution today is Jenkins. So what is Jenkins, and why is it the favorite CI tool of so many users? This paper will take a look at Jenkins, and why it is such a popular choice when it comes to CI.
The process of getting Jenkins running a regression is a simple and straightforward process, and one aim of this paper will be to walkthrough that process. It will also show the types of data that can be extracted from a regression, both in terms of an individual regression run, as well as historical analysis over an entire project. This allows a team to see trends in metrics such as build times, test pass and fail results, as well as coverage, all directly from within the Jenkins web dashboard.
We will also look at how having an automation server tied directly into your source code management (SCM) system, allows for tests to be automatically ran everytime a user checks in code. This helps to ensure that a stable branch of code always exists, and with frequent checkins, helps teams to spend less time integrating large changes Figure 1. Continuous Integration Flow which often result in multiple issues. In the event of a failed regression we can quickly alert the submitter who is responsible such that a solution can be found, ensuring the repository returns to a stable state as soon as possible.
One of Jenkins biggest advantages is the large community behind it which is continually creating new plugins which enhance and add to the features of Jenkins. Additionally, we will take a look at how we can leverage the vast array of plugins that are available via the Jenkins community to better analyze the results generated from Jenkins, and get the most out of the new CI environment created.
Introduction:
As verification engineers, we are always looking for ways to automate otherwise manual tasks. In case you have not heard, we are constantly trying to do more with less. Continuous Integration is a practice which has been widely, and successfully used in the software realm for many years. Deploying a continuous integration server such as Jenkins not only provides a way to automate the running of jobs, and collection of results, but it also allows for teams to reap the benefits of a continuous integration practices, which ultimately leads to a cleaner repository, with less integration headaches. Among many other benefits, Jenkins also provides a web dashboard to view and analyze results in a common place, regardless of how spread out your team may be. Its open source, has a strong community behind it, and you can start seeing the benefits by getting it up and running a regression in your environment before you even finish your morning cup of coffee.
Poster:
Source:
DVCon US 2017
|