devopsy.kinsta.cloud

Tag: pull request

  • Pull Request

    Pull Request

    pull-request

  • Pre-Commit Job Workflow in Azure DevOps

    Pre-Commit Job Workflow in Azure DevOps

    Many organizations use a combination of open so Many organizations use a combination of open source and commercial tools and Azure DevOps (formerly called VSTS) and an application lifecycle management (ALM) tool that includes features such as Azure pipelines. This article talks about how to achieve an end-to-end DevOps setup in Azure

    Pre-requisites:

    1. Subscription
    2. Project created with version control selected
    3. Process template selected (Agile/Scrum)
    4. Code repo–one on VSTS and one on GitHub/cloud GitLab
    5. Build server–Use credits from MSDN subscription
    6. Deploy–Azure subscription from MSDN
    7. Other tools–tools supported by VSTS/Azure DevOps
    • The objective of a pre-commit job is to reduce the risk of complexities, duplications and potential bugs in the code to get deployed directly into production.
    • In usual workflows, the build will be generated on regular intervals and released for testing. However, there is a chance of several code quality issues and building deployment issues.
    • With the help of pre-commit job, we can configure triggers to generate builds for every pull request made by developers. Also, this enables the development team to create pull request releases that deploy your pull request code or pull request builds, which help to detect deployment/release issues before the code changes are merged.
    • Pre-commit deployments also help catch deployment/release issues early in the cycle, maintain better code quality and release with higher confidence.

    Configuring Agile Board in Azure DevOps for Project Management, and Tracking Steps to Do It

    Steps:

    With Azure Boards we can plan, track and discuss work across different teams. With Azure Boards, we can swiftly and simply start tracking tasks, features and bugs of our project.

     

    For every project we have to create on sprint, go to Boards and select Work Items to create a new user story and provide the acceptance criteria. Select Boards and create New Work Items, then under Epic select User Story and click on Task and provide the task description.

    Setting Up Branches, Version Control and Branch Policies

     Steps:

    • Import the code from VCS.
    • Under Repos, create branches such as dev or test.
    • Set up the branches policies to improve code quality.

    Improve Code Quality With Branch Policies

    Branch policies help teams protect their important branches of development. Branch policies enforce a team’s change management standards and code quality.

    Setting up Branch Policies for Review Code

    Code reviews are good practice for the most successful software development projects. We have to configure the minimum number of reviewers to review the code and complete the pull request.

    • The code review done in a pull request is simply to find obvious bugs.
    • Code reviews help protect the team from bad commits or merges and broken builds that hinder team’s productivity.

    The review will help to catch these kind of problems before the merge, protecting our important branches, such as the release branch, from undesirable changes.

    Pre-Commit, Enabling Pull Request

    Steps:

    Workflow to complete the pull request:

    • Create a pull request
    • Complete a pull request

    Benefits of pull request:

    • Peer review
    • Enough testing and better stability
    • Reducing conflicts
    • Continuous delivery
    • Clearer responsibility

    Create a pull request:

    • Pull requests combine the review and merge the code into a single collaborative process.
    • For every bug fix or new feature in a branch, we have to create a new pull request.
    • Add the members of the team to the pull request once the development branch build is completed without issues. Then members can review and vote on your changes.

    Link work items to your pull request:

    Select the Overview tab in Azure DevOps. Select the add link button “+” in the Work Items to relate your current pull request.

     

    Complete Pull Request:

    • The basic policy requires that some reviewers approve the code with no rejections.
    • If Allow users to approve their own changes is not selected, the creator of the pull request can still vote Approve on their pull request, but their vote won’t count toward the Require, least reviewers policy.
    • If any reviewer rejects the changes, the pull request cannot be completed unless the allow users selection is completed, even if some reviewers select Waiting or Reject.
    • To reset code reviewer votes when new changes are pushed to the source branch, check Reset code reviewer votes when there are new changes.

    Nightly CI Build

    Steps:

    Build Triggers:

    • We can configure the build triggers to generate war package for every code commit made to the branch.
    • Under Build select Triggers to enable CI and include master branch.
    • One can enable the build trigger for every commit made to the branch.

    • Configure two builds—one for dev branch and one for master branch.
    • If the developer executes the code, the dev branch build is triggered automatically with help of dev branch polices.
    • Once the dev branch build is completed, reviewers approve the pull request and the master branch build is triggered. Once the build is completed, it moves to the release part.
    • The code quality analysis and unit test/Junit test is configured in the dev branch. The code quality gateways such as code review and find bug have been enabled.

    Continuous Deployment (Release) through Azure Kubernetes Services (AKS)

    Pre-requisites:

    • Any source code management tool such as Git/SVN or Azure Repo
    • Microsoft MSDN account
    • Azure account creation and VSTS/Azure DevOps account creation
    • Dockerfile to be created and placed along with source code in Git
    • YAML file to be created and placed along with source code in Git
    • Kubernetes cluster to be created in Azure portal
    • Docker hub account or Azure Container Registry
    • Build definition–Docker build image

    Docker File Creation for Application to Deploy

    Create the Service Principle to provide the access to the application/Docker image to deploy on Azure Kubernetes services. Select the Deploy to Kubernetes task and make the following configurations:

    • Create new Kubernetes service connection
    • Select the command option for deployment
    • Provide the configuration file location i.e, Deployment.yaml
    • Select the container registry type
    • Select the subscription
    • Select the Replace Tokens task to append the tag number for an image automatically while pushing it to container registry
    • Perform the deployment and view the logs

     

    Test plans:

    Load testing:

    Pipeline History

    Azure Pipelines is used to automatically build and test your code project and make it available to other users. Azure Pipelines integrates CI and CD to continuously test and build your project and ship it to any target server. It provides the full-stack end-to-end flow of CI and CD through various tools integrated as tasks in Azure DevOps.

    Conclusion

    With Azure DevOps, you can set up end-to-end DevOps with tracebility, pre-commit, CI and deployment to Kubernetes.

     

    This article was co-authored by Srinivasa Rao Guntupalli, lead engineer at HCL Technologies Ltd. He works on various DevOps technologies such as Git, maven, Jenkins and cloud technologies including AWS, Azure, Azure DevOps/VSTS.

     

    — Naveen Manchem

  • Dependency Based Build Promotes the Freedom to Program

    Dependency Based Build Promotes the Freedom to Program

    Whenever I want to be amazed, all I need to do is reflect on the fact that the continuing development of the Linux operating system is done essentially by a community of volunteers. That’s right! One of the most popular and important operating systems is updated and maintained through donated labor. Any programmer anywhere in the world can make a contribution to improve the Linux kernel.

    That such a herculean undertaking is done though volunteer labor is mind-boggling. What’s more amazing is that the software created has an extraordinarily high level of quality. Let’s face it, working on the Linux kernel is not something a kid in high school with a year’s worth of experience programming in C can do. But, any kid in high school can make a contribution to the Linux code base, provided the code passes muster. That it happens is almost magical, in a way. But it does, every day.

    What enables such freedom? To my thinking, it’s the concept of the the pull request.

    The Powerful Elegance of the Pull Request

    The pull request is a simple yet important part of the open source development process. A developer creates a feature branch off the Master branch of the Linux repository, then adds to or modifies the code in that feature branch. Of course, the developer writes tests that verify the new code works. Once the code is complete, the developer sends a pull request to the project, which is typically hosted on GitHub or another popular Git repository platform. The project maintainers, a group of people who have expert knowledge of the code base, review the pull request using tools that are baked into the Git repository platform. Each maintainer inspects the code and, if the code passes inspection, the reviewer votes to approve. If the code has shortcomings, the reviewer makes suggestions for improvement directly in the code using the Pull Request Commenting features, which are available in practically all the Git Repository Platforms including GitHub, GitLab and Bitbucket.

    It’s a simple yet powerful process and one that has changed the way enterprise-worthy software gets created. Any developer can implement an idea any way they want, as long as the implementation is compatible with the code base. It’s up to the developer to figure out how to do what they desire; nobody is dictating anything. The process is straightforward: Figure out how to make your contribution to the code. Make a feature branch. Do your work. Do a pull request. If your contribution is useful and the coded well, you’re in. If not, we’ll try to help you make it better.

    Bringing Git to Mainframe Development Using DBB

    The pull request is a compelling approach to making software—so much so that IBM has made it a central part of software development on the mainframe. And, its product, Dependency Based Build (DBB), streamlines the mainframe pull request process by reducing the work reviewers need to do in the code review process.  [su_pullquote align=”right”]A Dependency Based Build trial is available in the IBM Z Trial Program at zero cost, and with no installation required. The trial environment includes hands-on tutorials.[/su_pullquote]

    Git version control is supported by practically all the modern IDEs. For example, developers can configure Visual Studio Code, JetBrains products and Eclipse to work with remote Git repositories automatically. Once integrated, Git operates behind the scenes, allowing developers to work under version control without having to issue Git commands directly. IBM’s mainframe integrated development environment, IDz EE, provides Git integration as well. This is a big deal, as Git is now part of the mainframe ecosystem. The developer accustomed to using Git version control when working on a standalone x86 Java app now can move over to developing for a mainframe without having to learn a new source control management (SCM) system. But what’s even more impressive that Git is used as the SCM for more traditional mainframe artifacts; for example, COBOL source code.

    Also, Git integration goes beyond developers working on source code; Git is used throughout the mainframe build process—which, by the way, can be controlled by Jenkins. And, Git is a foundational technology used by IBM DBB, a dependency control agent that works with Git to make sure that all files—source and dependencies—in the mainframe build process are current. Again, this is a big deal: Having all the moving parts in the mainframe deployment process, from programming to build to release, use Git as the common code repository allows z/OS mainframe components to be part of a platform-agnostic deployment process. Use of DBB overcomes a significant hurdle between the mainframe and distributed world.

    So, what does this have to do with the power of pull requests?

    Adding Pull Requests and Code Review to the Mainframe Experience

    The pull request review process is more than just “looking at code.” When you have a project that might have millions of lines of code, such as the Linux kernel, no developer is going to pore over each line of code. They’ll read the documentation, run the unit tests, look at the lines of code that have been added or removed and search for blatant problems and inefficiencies. Now, on a PC, compiling something such as the Linux kernel is straightforward—all the code is in the single repository. On mainframes, however, it’s a bit different: The code is more widely dispersed and dependency management can get tricky. DBB takes care of tracking dependency changes in various Git repositories, so when it comes time to do the pull request, the reviewer doesn’t have to waste time resolving dependency issues to get mainframe code to compile. DBB will take care of that. With regard to the pull request, reviewers can do what they are supposed to do: make sure the code works and the quality is such that it can all be merged back into a master branch.

    This might not seem like much, but anybody who has stayed up until 3 a.m. trying to resolve dependency issues understands the importance of having code that builds all the time, any time. This is the power that DBB brings to the table.

    The Freedom to Program

    Programming is a special vocation. It requires an unusual combination of art, science, creativity and engineering discipline. Also, it’s not a vocation that lends itself to well to prescription. Each programming project is special, requiring new ideas. And new ideas come about when developers are free to use their imagination to think differently. The pull request is one of the best ways to ensure developers have the freedom to program in way that produces useful, high-quality code. DBB extends the freedom to program to the mainframe community.

    History has shown that when a developer is given the freedom to code and a community in which to code, the result is great software. Just ask Linus Torvalds.

    — Bob Reselman