Build, test and preview an app
Jenkins X developer environments should be familiar to anyone who has developed in a Git environment, with added features that further automates development processes, builds, and promotion.
The traditional development environment
A common workflow in a Git development involves:
Forking - The developer creates a fork of the project repository into their personal repo.
Branching - The developer creates a branch of their fork, for various reasons:
Creating a new feature
Fixing a bug
Applying a security patch for a vulnerability
Committing - The developer commits the code and pushes it to their branch, creating a
Creating a pull request - The developer creates a pull request (PR) from their branch back to the main repository
Testing - A developer peer or quality assurance (QA) team member looks at the code and/or builds a test version for validating the feature or fix, finding bugs and suggesting changes if necessary.
Merging - The PR code, if accepted, is merged into the master or main project repo.
Jenkins X and the developer process
Development with Jenkins X is similar to the traditional Git development workflow, with the added benefits of continuous development via automation within a Git context, also known as GitOps.
Jenkins X goes one step further by offering a preview environment that allows developer peers and QA testers to validate new features and fixes using an evaluation build of the functionality within the Git PR.
Generating a preview environment
In a typical Jenkins X development scenario, users make changes to an application that has been imported or created via one of the various supported methods, such as Quickstarts, imported projects, and Spring Boot applications.
When the developer makes the change to their branch, with the ultimate
goal of merging those branch changes into the
master branch for
deployment to production, they save their changes from within their
integrated development environment (IDE) and commit it to the source
repository, such as GitHub. The process to generate a preview
environment is typically like committing code in a traditional
A developer makes a branch to their local cloned source repository to create a new feature:
git checkout -b acme-feature1
The developer makes changes to the source code in their branch and adds the affected files to the commit queue:
git add index.html server.js
The developer commits the files adding a comment about what has changed:
git commit -m "nifty new image added to the index file"
The developer runs
git pushto send the code back to the remote repository and create a pull request:
git push origin acme-feature1
The program displays a link to a pull request. The developer can highlight the URL, right-click and choose Open URL to see the GitHub page in their browser.
Jenkins X creates a preview environment in the PR for the application changes and displays a link to evaluate the new feature:
The preview environment is created whenever a change is made to the repository, allowing any relevant user to validate or evaluate features, bugfixes, or security hotfix.
Testing the preview environment
The development bot created during the installation process sends a notification email to the developer as well as the designated repository approver that a PR is ready for review. During the approval process, the approver can click on the preview application with the code changes for testing and validation.
When the approver confirms the code and functionality changes, they can approve the with a simple comment that merges the code changes back to the master branch and initiate a production build with the new feature:
The code is merged to the
master branch, and the release is pushed to
staging/production or a release created and available from the GitHub
staging environment in the
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.