What is your primary use case for Jenkins?

We use Jenkins for CI/CD and infrastructure automation. It is primarily used for application deployment, and we deploy Docker containers to our Kubernetes cluster.

I use Jenkins for CI/CD pipelines.

In our CI/CD pipeline, we rely on Jenkins to trigger various tasks related to the Telco Cloud infrastructure. It's an essential tool for managing our infrastructure tasks efficiently.

Jenkins is used for continuous automation of the various stages of the software development life cycle, such as building, testing, and deploying code chains. Jenkins supports continuous integration, allowing developers to integrate their code chain into a shared repository multiple times in a day. Jenkins has a large number of plug-ins available for source code management, build tools, and testing. Jenkins integrates with various version control systems like Git and Bitbucket. Since it has a pipeline, Jenkins supports the creation of complex builds and deployment for a flow using the pipeline plugins. Jenkins provides security features such as user authentication, authorization, and role-based access control. The solution integrates with external identity providers for authorization.

We're using Jenkins for projects. We just need to run Jenkins pipelines and stuff. We use iPlus for web application testing automation. Multiple people can work on the same piece of code. Once we push the code to the Git repositories, by default, we need to check if it's working and if the code passes the tests. If any tests fail, we need to verify the logs in Jenkins. So, those are the main things we do with Jenkins.

We mainly use Jenkins as a CI/CD setup for our development, as a build tool to build, test, and deploy.

We use Jenkins in CI/CD pipelines.

We use the solution for continuous integration and deployment.

As an administrator, I manage Jenkins. The development team uses it more frequently for automation and CI/CD.

For the deployment of modules, we use Jenkins in our company.

We primarily use the solution for CI, continuous integration, and as a content server.

We were developing software, which would get built after we committed to version control. Jenkins would pick it up, build the software, run tests on it, and upload it to JFrog if everything was okay.

We are using Jenkins to automate the compilation and check the implementation from scripts for validation and testing. It's a useful tool for any developer. If the code works fine in the company's development environment, it doesn't mean that it will be okay for other platforms. We're using Jenkins to test the server in platforms. It's very helpful.

We use Jenkins for CI/CD application. It helps us develop and push out applications.

We are using the solution for integration purposes. We have our own DevOps pipeline. Jenkins is the key tool that is being used in the entire DevOps journey. It's like an automation build tool. It's a CI/CD: continuous integration and continuous deployment

We usually just use Jenkins for the CI, continuous integration, part. That is the use case we have.

The solution is a continuous integration tool.

I am using Jenkins for my automated deployments for one of my projects.

We use this solution to build, test, and then deploy new software to the FTP server.

We use this solution in conjunction with Java which is installed. We have to give it the main part, our desk framework and the GI repository. The solution automatically takes the code from the GI repository and automatically executes it as a face task. It could be done at a set time for minutes, hours, and any day of the week. For example, if we want to get it right every day, it has to be set automatically to take the quote.

We are using Jenkins for running our test jobs, and multi-cluster deployments in the cloud.

We use Jenkins for integrated reporting. We have different projects that require coaching, gate configuration, and clone effects. We build packages, deploy, and upload-pack eights. We start at software changes and follow the process through to final testing and eventually launching.

I mainly use Jenkins to create automatic triggers for pushing code.

We're deploying our pipeline through CI/CD with both engines, most use it for CI purposes only. We are building our CAR files and deploying them in the endpoint cluster, such as Kubernetes as well as on-premise systems. We are using the management where I can write playbooks and deploy them. I call the playbook through the Jenkins Groovy script. We can do multiple instances, at a single time.

Jenkins has good plugins and a secure platform.

We use Jenkins to trigger the URL and necessary files in a batch. Jenkins is integrated with Jira and Litmus. We'll put a URL into Jenkins and trigger it. We can schedule it to run overnight every day, week, month, etc. Multiple teams are using Jenkins, and it's integrated with multiple Jira plugins. I believe around 250 people using it.

We have multiple job templates available. You just need to find the best template for your needs. If you just want to do a Maven build, there will be a more suitable template there. For something else, if you just have one rebuild and you want to deploy it from the server, there will be some other job template available. We have multiple job templates, so we need to configure according to that template and then it's okay. The solution is deployed on-premises. About 15% of my organization is using this solution. It's basically used by the DevOps engineers. Not all the developers use it.

Our main use cases are for restarting applications and monitoring system health. We instal the solution for companies and once it's up and running, we do all the health checks. We are customers of Jenkins and I'm a DevOps engineer.

We primarily use the solution as a build automation tool. If we have to do some automation, we have to deploy the code on a server, and on the production server, so we can create a Jenkins pipeline, which we can call from Jenkins itself. Therefore, whenever we want to deploy the code on a server, on the production server, we use the Jenkins pipeline.

We are an automotive infotainment software provider. Our products are for infotainment. We have displays or music systems that are dealing with the Android operating system, and we are using Jenkins for some of the jobs. We have two deployment models. One is on-premises, and the other one is the private cloud.

We use Jenkins for deploying with GenX and work on the pipeline too. We engage in many activities using both Jenkins and GenX.

We use this product as an open-source CI/CD. It allows integration, building pipelines, and even linking them to Azure or AWS platforms. It is an open-source tool. However, I wouldn't call it a public cloud. I would refer to it as an open-source tool for continuous integration and deployment. It can be integrated across every platform. Our primary use case for this solution is creating pipelines for some projects we work on. Additionally, we use it to build pipelines and provide them with commands. For example, if we want to make a Docker image or send the deployments to Azure then we can integrate them into the Jenkins app service instead of Azure DevOps.

Jenkins is used for triggering my test automation. I use Selenium WebDriver for test automation.

We use Jenkins to build and deploy our software.

We use Jenkins for management purposes.

Jenkins is basically used as a CI/CD tool, wherein you can integrate multiple tools that are part of your delivery pipeline. Jenkins is basically a controller for your delivery. For example, what happens, when it happens, and in what sequence it happens can be controlled by Jenkins.

When have to execute continuous testing with schedules and after test, if we want to run additional validation and verification we use Jenkins. Jenkin can do additional validation of our test executions of the results and collects data points.

I primarily use Jenkins to deploy APIs for microservices, creating pipelines and providing the source code link.

We use the solution for the whole automation cycle for the deployments. We are using Jenkins and pipelines for once commits or push commits on Bitbucket or directories. Jenkins is listening for those changes and is applying (or triggered by) the repository changes to deploy and run the test cases, automate test cases, and deploy them on servers for the deployment, testing, or production.

I'm using Jenkins for CI/CD pipelines. We have around 400 dashboards and BI applications that need to be deployed when we make changes and push it all out on GitHub. I create webhooks from GitHub to trigger the Jenkins pipeline, which runs a script that I'm writing in Python. This deploys the applications to their respective application servers.

We use Jenkins for building our applications, deploying our applications, and some automation tasks.

I use Jenkins for the continuous integration and continuous delivery phases of my pipeline. For the continuous integration part, we use GitHub with Webhook. If we have a development environment and the developer pushes anything, Jenkins will trigger the job right away. But if it is going to stage all the production environments, then Jenkins will start the job, and the developer will create a pull request. We can see that the test cases have passed, and the GitHub branch is ready to be merged into the feature branch. And for the continuous delivery pipeline, we are pushing things ourselves through Helm. So whenever we have to deploy something, we have created or developed our stages, through which we use Helm charts and deploy our solution. Since we are using microservice architecture, most of our infrastructure is Kubernetes-based, which means we use docker containers inside that and cloud environments to spin up our solutions quickly. Jenkins is running inside Kubernetes, and Jenkins has some hooks attached to it. And with the plugins attached, you can spin up the container on the go whenever we have to build a job. And when the job is complete, the container is deleted. It's not like we have some node in Jenkins. The architecture comprises a master and a slave node, and you can run jobs on the slave node. Our slave nodes work under both containers, which we are only spinning up when we need. And when we are done, we are just stripping them out instead of having our virtual machines running all the time. That is an interesting aspect of this architecture for us. Microservices waste architecture, so we use Kubernetes infrastructure with containers to spin up our slave nodes and handle the workload or the computing. We use Jenkins for everything. We want to empower developers to have the confidence to deploy their solutions themselves into production instead of asking us as an operations guide. Even if they have to create a repository in GitHub, we have scripts behind Jenkins that can go ahead and make these for them. It's a core component of our development pipelines and developers' lives in our organization.

My primary use case is as a CI pipeline in order to deploy onto the GCP. This allows us to push any changes into the master brand.

The primary use cases include manifest generation and publishing modules.

I'm a software engineer at a large bank.

There are many use cases for Jenkins. We have an AWS infrastructure in which we have created templates for the provisioning of the infrastructure, and for the infrastructure network appliance, we use Jenkins. For the builds, we use Docker images, Maven, Gradle, and other builds. We send all the build environments to the Artifactory Servers running Jenkins. For any deployments to the systems, such as any standalone machines, Kubernetes cluster, or Auto Scaling groups, we use the Jenkins. If a Kubernetes cluster is ready and you want to have other external configurations we use Jenkins for all of the configuration setups. Jenkins can be used to check vulnerabilities of any system or Docker images.

This solution is open source and we use it for the entire bill pipeline - for building different languages, for running reports on code coverage, running our QA tests, automated tests, and for deployment. We are customers of Jenkins and I'm head of infrastructure.

Our company is in development. We provide development solutions for our clients. Jenkins is a code repository. We use it for the code repository.

We use it as a pipeline and for the whole development life-cycle. We even built the whole infrastructure and use it with cloud formation. In AWS, we use it with cloud formation when we build the infrastructure as a code.

We use a Hybrid cloud. We are deploying internally on our own servers i.e. our virtual servers in Microsoft Azure. We have 6 engineers using Jenkins Primer. It is only for internal use. We use it for the automation pipeline in our development of software. It compiles and moves the software to deployment in the Microsoft Azure cloud. We also use Jenkins to generate documentation for all the software.

We used it for continuous integration and had its latest version in the previous organization. I am now using Azure DevOps.

We use this solution for repeatable testing of code for regression and design conformance in a medical and scientific environment.

We use this solution for Build & Deploy Automation. It is integrated with Git or TFS, Nexus and Ansible for deploying to premises servers in Linux or Windows.

We use this solution for continuous integration and deployment, using Groovy Script for pipeline node configuration.

Jenkins is part of our test infrastructure. We organize the test execution mainly of our performance tests, based on JMeter. Second, the deployment of release candidates in our test infrastructure is managed using Jenkins. In the future, we want to use Jenkins more in the field of continuous integration and continuous deployment.

This is our CD solution for Java APIs and Microsites.

This solution is the primary component for our automatic release process, including code smell, integration, and deployment.

I use Jenkins for Continous Integration or Continous Deployment to run test case execution in Nightly build atmosphere. Integrating test scripts to Jenkins is easier and it can run based on the frequency mentioned in settings.

We use it for build.