Your Privacy

This site uses cookies to enhance your browsing experience and deliver personalized content. By continuing to use this site, you consent to our use of cookies.
COOKIE POLICY

Breaking Down DevOps | Part 2

Breaking Down DevOps | Part 2
Back to insights

This article is the second in a series discussing trends, tools, and processes related to your Software Delivery processes.  We will uncover how taking on a DevOps mindset and making incremental changes can have a tremendous impact and ROI to your organization. In this installment, we explore a foundational component to DevOps, effective use of source control and planning for the throughput which DevOps will bring to your teams with best practice branching strategies.

Are you using source control effectively?

Version control is the foundational component to development teams. It acts as the recorder of development history and catalyst for enabling high performing development teams to multi-task. There are several choices out there for source control – most notably Git and Subversion.  The two are based on two different paradigms: distributed versus centralized, respectively.  As some of you may know Git was used as the source control technology of choice for linux kernel development.

At UDig we recommend moving teams to Git for several reasons:  Git allows for remote development which is faster, more powerful, and takes up less space.  For those who previously held onto Subversion for the lack of visual clients for Git in the past, there are now several options including Sourcetree and TourtoiseGit.  However, whichever route you choose, the step of getting your organization to adopt source control is an absolute must and a foundation for moving towards a DevOps culture.

Successful Branching Strategies

After choosing a solution for your source control the next step is to define a branching strategy. Over the years many different branching strategies have evolved: stable trunk with all development in branches, release branches with all development in master, using pull requests, and GitFlow.  Our end goal of Continuous Delivery and keeping software development as efficient as possible with an emphasis on team communication shifts our focus to keeping all development in the mainline and avoiding long-lived feature branches.

Developers should pull and commit often, avoiding large check-ins that can cause conflicts.  The goal here is to have every commit result in a build that should be able to be pushed to production (or at least a production-like environment).  Feature branches might seem to make a lot of sense…working in isolation without the fear of breaking another person’s code or having someone else’s code break theirs.  However, a couple things can result from this, the developers will develop in their isolated branches and one developer could be left with a very messy merge.  Also, when any refactoring work needs to be done the resulting renaming or moving of files can create large conflicts.  So to avoid this, developers tend to be less likely to attempt refactoring in fear of these types of conflicts and the team is left with an untidy codebase.

Instead we encourage developing together in mainline which promotes smaller and more frequent commits and easier to maintain merges.  This also encourages the team to communicate more often when conflicts do arise taking a look at how to refactor shared pieces of code, and keeping a much more tidy and easy to maintain codebase.  Resolving issues quickly is essential since the mainline of code should remain healthy and theoretically be able to be deployed to production at any time (given the build is passing).

One of the primary goals of continuous integration is that every build should be able to result in a push to production. Having a mainline development strategy forces developer code integrations and a stable code base.  Adopting a mainline development strategy, one might ask, “What happens if a feature isn’t ready to be released to all customers?”  In the past, feature branches have been used as a weak attempt at modular architecture – releasing only branches of code when the feature is ready to be fully released.  Instead, patterns such as feature toggle should be implemented to control who has access to these new features (if anyone).  If the feature isn’t code complete and seems to be affecting other functionality, then take a look at the above paragraph.  The codebase should have been refactored to separate the concerns of that one piece of code.

The ability to cherry pick commits is no longer an option with Continuous Integration and Continuous Delivery models.  CI and CD force communication within the team when a developer goes to pull and notices a conflict or issue immediately.

Recently, we developed 5 Misconceptions about DevOps, a guide highlighting the top misconceptions around DevOps today and sharing our perspective on the true state of DevOps today.  Download it today and get it touch to talk about the DevOps strategy for your organization.

Digging In

  • Digital Products

    The Growing Importance of Digital Accessibility

    Embracing Digital Accessibility: A Moral and Business Imperative In today’s digital landscape, accessibility has become crucial for businesses and organizations. With increasing awareness and legal requirements, ensuring that digital products are accessible to all users, including those with disabilities, is not just a compliance issue but a moral imperative. At UDig, we champion ADA compliance […]

  • Digital Products

    Unlocking Business Potential: The Power of Custom Application Development

    Like any savvy business leader, you’re likely always on the lookout for tools to give your company a competitive edge. And in doing so, you’ve undoubtedly considered investing in custom application development. But the question is, how do you ensure that such a major investment in a custom web application development provides a strong return on […]

  • Digital Products

    Mastering Legacy Application Modernization: Strategies for Success

    The ironic truth of the business world is that change is the only constant. But this means that failing to keep pace with the competition and its technologies will only end with you falling behind. That’s where legacy application modernization enters the fold. When you modernize legacy applications, your team gains access to new features […]

  • Digital Products

    CTO Confessions Podcast

    In this episode of CTO Confessions, Rob Phillips, the Vice President of Software Engineering at UDig, digs into his journey from a passionate technologist in his youth to a seasoned leader in the tech industry. He shares valuable lessons on transitioning to senior leadership, the importance of understanding and articulating company problems, and the art of empowering teams for high performance.

  • Digital Products

    Navigating the Challenges of On Premise to Cloud Migration

    In today’s rapidly evolving technological landscape, the shift from on premise solutions to cloud-based infrastructure has become a pivotal transformation for organizations seeking to modernize their IT operations. This transition holds the promise of increased agility, cost savings, and enhanced scalability. However, it is not without its set of formidable challenges that organizations must navigate. […]

  • Digital Products

    The Power of Transferrable Skills in Tech Projects

    Every project has its own unique elements that require flexibility to be effective and achieve success. This often requires picking up new pieces of a tech stack, learning a new programming language, or a new project methodology. Fortunately, there are also many transferrable skills that carry over from one project to the next. In my […]