Jenkins – Overview
- Jenkins and its integration with LabVIEW
- Application usage
- Jenkins usage
- Jenkins architecture
- Job distribution
- Next Steps
LabVIEW integration with Jenkins
One of the most crucial parts of software development is CI/CD (Continuous Integration/Continuous Delivery). Importance of correct CI/CD increases over time, as in most of the applications oriented for wide range of users, their success depends on customer first touch with product and even small possible bug can bury the success of application.
In Kentigen, we feel same and our goal is to deliver fully tested application to ensure best customer experience.
Main key to deliver tested product is to have established standardized environment for performing automated test and repeating actions. One of utilities widely used for automation CI/CD process is Jenkins.
Main advantage is his open-source philosophy, many active members and variety of free toolboxes. All of those making this product predetermined for success.
In Kentigen, we are developing ADAS software solutions, which are critical from point of reliability and stability. There is no space for unexpected behaviour or human error.
We have decided to use Jenkins for CI/CD for testing and deploying Hardware-In-the-Loop software solution for FrontCamera simulations/testing.
Majority of current CI/CD solutions are focused on testing “just” software product. Our Jenkins usage is unique in terms, that we are not validating standalone software, but our product is hardware based. This adds additional layer to problem complexity and for us a “problem solvers” unique challenge to deal with.
- Building .exe version of our product.
- Analysis code quality
- Perform test with feedback from hardware
- Create report
All those tasks were performed manually and often leads to errors. Application of Jenkins reduce time and errors created by manual testing.
System architecture is critical from point of scaling product in the future. Wrong architecture could lead to issues with implementing new steps and overall difficulties during application scaling.
Jenkins is a server-based application, so it’s possible to allow multiple devices communicate with each other. We also wanted to integrate 3rd party product, which we are using on everyday basis, to improve experience working with Jenkins.
We proposed Master – Slave architecture.
- Server dedicated for job distribution.
- Is triggered by commit.
- Delivering results .
- Responsible for particular task.
- Triggered from Master.
- Pushing feedback (result) of job’s back to Master.
Main task to distribute Job among the slaves is performed on Master device. For this we used possibility of Pipeline:
Pipelines requires little deeper knowledge of syntax and are not so intuitive as basic Jenkins environment (Freestyle project). Their advantage is complexity which they bring and scalability of particular event.
After commit is pushed to repository, Master device is automatically triggered. In Jenkins environment we could set up trigger events.
By those triggers, the main pipeline is started.
Appropriate actions are triggered by special keywords in commit message.
In our case we use following keywords:
Each keyword cause to perform different job and it prevents us from performing time consuming operation in situation when we do not need them.
By selecting appropriate keyword, we can continue to perform required steps.
All those steps are defined as Stage
To speed up process, we encapsuled functionality of partial task into Jenkins Item: “Freestyle project”.
Their advantage comes from nice and friendly user environment and instead of Pipelines, there is not required so much knowledge of syntax and toolboxes. Also, there are tons of Plugins available for Freestyle project online.