Remote Deployment of Test Tool onto Build Server
Background and Environment
We deployed our VectorCAST unit testing tool on a server running Linux during a recent evaluation at a large Avionics company in East Asia. This server hosted the compiler for Linaro Linux, one of the embedded Linux flavors that can be found on the market. The client accessed the compiler via SSH from their Windows workstation. A shared drive would make the code and compiled binaries available on both the Linux server and the Windows workstation. To test, they would upload any program to Linaro from the Windows workstation.
Deployment of VectorCAST on the build server is the preferred solution because the compiler is located there. This is relatively straightforward to do. Most Linux will let you connect remote graphical user interface terminals using X-windows system. A proper command from the SSH client on Windows alongside with the installation on Windows of a X-windows server solution like XMing would be all that is needed. These methods are often free to use.
VectorCAST interface and its functionalities on Linux are the same as on Windows. The only difference to the user may be a small delay in screen refresh; but with a sufficiently fast network, the difference is minimal. In fact, when developing our solutions, we tested from a computer located more than 100 kilometers away from the office and connecting through VPN and found the responsiveness to be quite acceptable.
That left one technical hurdle to overcome: test execution. If the target would have been “visible” from the build server, the integration would have been straightforward. VectorCAST can integrate with a great variety of embedded systems, including these that are Linux-based. In this specific case, direct communication from the server to the board was not possible, the execution would need to transit via the Windows workstation.
One possible option would have been to install some kind of SCP/SSH server solution on Windows and use that access to, in turn, access the Linux Linaro board. This would make it mandatory for the customer to install such a server on all Windows workstations where VectorCAST would be used. That would be a non-trivial impediment to usage.
Instead, we opted to design an agent program on Windows to automate execution, leveraging the communication resources that were already installed in the development environment, namely the shared drive with the build server and the ssh/scp connection to the Linaro board. This proved to be tricky on two fronts. First, we needed to be extra careful about possible race conditions in the shared drive and ensure that files saved there were fully saved before being accessed. These were resolved in full. Second, we realized that the ssh/scp password mechanism may be problematic since passwordless automation that we deployed on other such systems actually failed with Linaro. We resolved this issue by using the ssh client used by the customer.
The agent requires the user to provide a few settings. When every required field is correctly filled, it starts to listen for specific events from the build server. Once these events are detected, it executes the tests onto the target. To do so, it may leverage a number of ssh/scp executables (Cygwin, OpenSSH, puTTY). It also has a mode that enables VectorCAST field application engineers to use the agent with other systems that may not be ssh/scp based.
We believe this is an optimal solution for most of the situations where a build server is to be used, as it relies on tools that are already installed and/or are available for free download. The architecture of the agent quite flexible so customized solutions can be devised from it by VectorCAST engineers. If you have such needs, please contact Vector support.