We all know that Jenkins is an open source Continuous Integration tool which lets us build, schedule and execute our automated suite on different environment to verify daily commits and changes. However, very few of us know that it can be used effectively with different options integrated to Automation Solution. Let’s understand the different areas it can be implemented effectively.

Why any project should adopt master and slave?

In this complex technical world, a Tester is expected to validate application with maximum coverage by adopting risk based techniques. Tester also needs to assure cross-browser and cross-platform environment testing for every new frequent builds for zero defect leakage, hence it is not cost effective to verify every committed builds on different environment manually. Jenkins is used for Scheduled/Non Scheduled execution. Jenkins can handle 100+ machines and distributes the workload to them automatically. This can create various build sections that supports all the environments that you need to run build/test within. It has the capability to configure slaves on cloud platform (like Amazon EC2/SaaS) and build the test. Better ROI is achieved after this implementation.

Jenkins Master Slave Features

 

How different it is on Executing on single VD?

Parallel execution is key success factor for better test execution rate, hence multiple slaves are recommended. We can run slave and master on single physical machine also. It would be advisable to have better hardware configuration of machine for better performance. Utilization of only one VD depends on execution requirement.

How and why you can control slaves?

To control the slaves like (Connect/disconnect/configure/offline) are accessible only for users having the permission. Let’s say for Production Test Job we would be required to utilize dedicated slaves as much as possible and different slaves as needed. For example we have 4 physical machines and of which one is master, in project there is a requirement to execute automation suite daily on Dev, QA and Production environment. You can define slave names accordingly (e.g.. Dev Slave, QA Slave, and Production Slave) and can configure the job to run on specified slaves only. Once execution starts the respective job will run only on assigned slaves. If your job is idle then we can disconnect the slave too. It will help us to minimize the cost on demand usage.