Key Points
This article was originally published on TestProject - Test Automation Blog
The following will introduce in detail the continuous integration (CI), an essential practice in software development, and Jenkins, the industry-standard open source continuous integration tool. By implementing continuous integration and Jenkins CI servers, you will learn how Jenkins deployments can help your development team release higher quality software and save valuable time.
Want to learn more about Jenkins and Continuous Integration? Please check the following link:
Modern software development practices require the deployment of fully functional software as soon as possible or frequently in production environments. For example, an agile approach enforces this behavior directly by having the team work in small increments and deploying it to a production environment after each sprint (read: Test automation strategies for agile projects).
The development team spent months developing the software and then passing it to QA, UAT and all production lines no longer exist. Today, the focus is on having a fully functional software and never allowing situations that endanger software quality, such as introducing important software changes at the end of the release cycle. This is where continuous integration comes into play.
CI is a practice that enforces strategies to frequently integrate tested code into stable branches of projects. I would like to emphasize "tested code" in particular, as this means that the functionality developed on separate branches is also tested and therefore integrated into stable branches.
Usually, DevOps engineers are usually responsible for setting up CI pipelines. Today, the role of DevOps engineers is very similar to that of test engineers, because both ensure process and software quality. I usually say that QA and production are the closest intersections to customers. In this sense, CI provides test engineers with a very powerful tool to improve overall process and software quality by actively participating in the following areas:
The development team has its own source code version control repository that contains projects (usually GitHub today). A stable branch (main branch) is often considered a work branch and rarely develops new features directly on the main branch. Instead, developers create their own branches to develop new features (branch A of feature A). When changes are pushed to the repository on that particular branch and the developer makes a pull request, some basic test set (smoke test) should be performed against that branch. From a CI perspective, this usually means the following:
When the CI process is completed, there are some requirements from the perspective of test engineers and developers:
Smoke testing saves a lot of time for developers who will be undergoing code reviews and test engineers who need to retest feature A on the pull request branch. If the smoke test on the pull request fails, then the developer responsible for Function A is now responsible for fixing the smoke test feature and issuing a new pull request (until the problem is fixed, the problematic code will not be merged into the main branch) .
If this is done, and the new code for function A is merged into the main branch from the perspective of CI, the following will occur:
This indicates that the merge was successful, the smoke test function is still valid, and now it is the responsibility of the test engineer to retest feature A on the main branch again (to make sure the merge does not have any side effects on feature A). Of course, it is a good habit to enhance the test automation suite over time to cover most of the features.
This becomes increasingly important in late iterations of the project, as the test engineer has more tasks (testing current features and all previous features). This is where regression testing comes in handy: From a CI perspective, the execution of regression tests usually occurs when the test engineer explicitly runs the regression test or when using a scheduler (for example: performing regression tests every night). It's a good habit to customize this job so we can specify which branch this job will be performed for (here you can read more about why and when to perform regression test automation). The process is as follows:
Homework: The most important "unit" in Jenkins terminology is homework. A job is a single execution unit in a Jenkins CI server and must have certain results (pass/fail). For example: the job can be a deployment job, a smoke test job, a regression test job, etc. Jobs consist of multiple areas executed in sequence, which will be explained in the next paragraph: The structure of Jenkins jobs.
Plugins: One of the main features of Jenkins test automation is the ability to customize it by using existing plugins or creating your own plugins. Everything in the Jenkins tool, from the job configuration section to the Jenkins configuration section, is actually a plug-in. Due to the large size of Jenkins’ community, various Jenkins plugins already exist to meet the needs of the most demanding CI workflow tasks. This means that you will most likely come across a useful plugin instead of creating a custom solution.
Node: In the simplest setup, the Jenkins instance will run on a machine, where all jobs will be executed. For small tests and small amounts of assignments, this makes sense. However, in practice, there are often cases where multiple teams use the same Jenkins instance. Since they have a large number of jobs, it is considered bad to execute on an instance for the following reasons: security, disaster recovery, performance, scalability, etc.
Enter master/slave in Jenkins: The Jenkins master node is only used to schedule jobs to be executed on the Jenkins slave. This way, the Jenkins host is not heavily used, and the team has its own slave machines that are the best size for their test automation projects. Furthermore, the slave node is then configured to process several parallel jobs to be executed (number of executors per node). You can also configure on-demand nodes from AWS. This means that the node only exists when a job needs to be executed on it. This is very useful because we want larger machines that will only be fully utilized when running regression tests. For this case, a larger EC2 instance will be launched on AWS on which the job will be executed and upon completion (based on the configuration idle time), the instance will remain active for a period of time. After that, it will determine which approach is more advantageous when using an hourly paid service, such as an AWS service.
In a Jenkins CI server, each Jenkins job contains multiple parts:
General: Here, we specify the project/job name/description, add job parameters as needed, define job log rotation strategy, etc. The next screen shows how to configure log rotation (you can specify the number of days to keep the build log or the number of last build logs to be kept), how to parameterize the job (by adding the string BUILD_ID with the default value of 0.0.1, however, this Values can be specified when starting a job) and how to configure where this job will be executed (slave node name):
Jenkins Source Code Management: As the name implies, this is where we define a source code repository (such as GitHub or Subversion) in a Jenkins CI server:
Jenkins build trigger: schedule job execution time (periodically, after other jobs, when GitHub pull request occurs, when changes are pushed to GitHub, etc.).
Jenkins Build Environment: Here we define options related to the environment the build will execute (delete the workspace every time the job is executed, abort the job if it is suspended for a period of time... etc.).
Jenkins Build: In the Jenkins CI server, this is the most important step for each job. The result of this step affects the status of the job at the end of execution. Depending on the installed plug-ins, many options are available, the most commonly used plug-ins are: executing shell, executing Groovy scripts, calling Ant/Maven/Gradle scripts, executing Windows batch commands, etc.
This is an example of a frequently used "execute shell" plugin that is able to inline your own shell script or execute existing shell scripts.
Jenkins Post-build Operation: This part of the job is used to report the results of the job or to call other jobs in the Jenkins pipeline. Generally speaking, we can send emails containing the execution status of the job, publish HTML reports, JUnit results, publish artifacts built in the build stage to S3, etc.
Please note how $BUILD_ID is specified in the subject line of the email. Since this job is parameterized, this value is specified when the job is started. This parameter can be used in the Jenkins build and post-build operations section of the job.
So far, you've learned the main benefits of Jenkins CI servers and how CI itself is added to the software development process and to the test engineers. Like any other technology, it takes time to master the basics and experience the advantages. I highly recommend that you invest your time in CI, which is definitely worth it in the long run. In particular, once Jenkins CI server is applied, many painful and repetitive processes will be automated and you will suddenly have more time to focus on product improvements.
Did your team also implement continuous integration and Jenkins CI servers? Feel free to share your team’s experience and ask questions in the comments!
This article was originally published on TestProject - Test Automation Blog
Jenkins and Travis CI are both popular continuous integration tools, but they have some key differences. Jenkins is a self-hosted solution that requires you to manage and maintain your own servers. It is highly customizable and can be configured to accommodate nearly any CI/CD workflow. Travis CI, on the other hand, is a cloud-based service that is easy to set up and use. It integrates well with GitHub and supports many languages out of the box. However, for complex workflows, it may not be as flexible as Jenkins.
Jenkins and GitLab CI/CD both offer powerful continuous integration solutions. Jenkins is known for its flexibility and large plugin ecosystem, while GitLab CI/CD has received praise for its seamless integration with the GitLab ecosystem. GitLab CI/CD also provides built-in Docker support, which can be a big advantage for teams using Docker.
Jenkins offers several advantages over other CI servers. It is open source and has a large and active community, which means it is constantly improving and updating. It also has a huge ecosystem of plug-ins that allows you to extend its capabilities to suit your specific needs. Additionally, Jenkins supports a variety of languages and tools, making it a common choice for many different projects.
Jenkins is a universal tool that handles continuous integration of Python projects. It automates the construction, testing, and deployment of Python applications and supports many popular Python testing frameworks. Jenkins also integrates well with version control systems like Git, making it easy to integrate into your existing workflow.
When choosing between Jenkins and Travis CI, you should consider factors such as the team’s technical expertise, the complexity of your CI/CD workflow, and budget. Jenkins requires more setup and maintenance, but offers greater flexibility and control. Travis CI is easier to set up and use, but may not be flexible enough for complex workflows. It is also a paid service, and Jenkins is free and open source.
Jenkins supports CI/CD pipelines from integration and testing to deployment by automating all phases of code delivery. It allows for continuous feedback as developers can quickly identify and fix problems in their code. Jenkins also integrates with a variety of tools in the CI/CD ecosystem, making it a common choice for implementing CI/CD pipelines.
Yes, Jenkins can be used for projects that are not hosted on GitHub. It supports a variety of version control systems including Subversion, Mercurial, and Perforce. This makes Jenkins a universal choice for teams using different version control systems.
Jenkins handles parallel builds by allocating tasks between multiple machines or executors. This allows for faster build times and more efficient resource utilization. You can configure Jenkins to automatically manage your build infrastructure or manually specify which tasks should run on which machines.
Some common challenges when setting up Jenkins include managing dependencies, configuring build triggers, and setting up secure access. However, Jenkins has a large and active community, so there are a lot of resources to help you overcome these challenges.
You can extend the functionality of Jenkins by installing plugins. Jenkins has a huge ecosystem of plugins that include plugins for a variety of functions from integration with different version control systems to improved user interfaces. If you need features that are not provided by existing plugins, you can also write your own plugins.
The above is the detailed content of Key Guidelines to Continuous Integration and Jenkins CI Server. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
