Kuali Days 2021 Registration is Now Open!

Continuous Delivery Differentiates Kuali Cloud Solutions

July 14, 2020

My colleague Brandon posted about the Benefits of SaaS for IT Departments. As a business consumer of multiple cloud applications, two benefits stand out when I’m comparing cloud to “on premises” technologies:

  • Lower costs (both installation and ongoing operational), and
  • More rapid recognition of value, without expensive upgrades

Unfortunately, few cloud providers are prepared to help you achieve both.  As more higher ed administrative applications move to the cloud, college and university leaders are starting to question what makes each product or vendor unique. In order to rapidly recognize the value of your investment, without waiting for expensive and disruptive upgrades, it’s critical to work with vendors committed to Continuous Delivery and Deployment. Software providers mired in traditional development and major release cycles can’t deliver on the full promise of the cloud.

Introducing Continuous Delivery and Deployment

What makes Google, Amazon and Facebook different than most enterprise solution providers? Continuous Delivery and Deployment. Development teams that aggressively practice Continuous Delivery use a variety of practices and tools which allow them to rapidly build and then test software in an environment that closely resembles what customers use in production. Continuous Delivery practices enable Continuous Deployment of software to customers in super small chunks, as they’re finished, rather than batching up features and saving them for major releases. This is beneficial because customers can see bug fixes, enhancements and big new features more quickly and at lower risk of having problems.

Drawbacks of Traditional (non-continuous) Deployment to Customers

In a traditional (non-continuous) product deployment environment, developers write code, save it into a code repository, and move on to other things. Over time, often many months, these code changes are aggregated into a “release.” By the time the release happens, the developer has changed contexts several times and doesn’t have all of the code changes in mind at the same time. When the release happens, a small problem can turn into a much bigger problem as developers, if they’re even still employed by the company, try to track down and fix problems in code they haven’t seen in months. The result is that project teams go overboard in creating bureaucracy and overhead around releases, with increased costs that are passed on to the customer. In addition, more bugs “squeak through” because so many code changes are happening at the same time, often in overlapping areas, that it’s impractical to find all of the issues.

How to Recognize Effective CD Practices

The premise behind Continuous Delivery is that a developer is most acutely aware of the context of a code change immediately after she has made the change. This is the best time to introduce the code into production. Doing so has several advantages:

In a traditional (non-continuous) product deployment environment, developers write code, save it into a code repository, and move on to other things. Over time, often many months, these code changes are aggregated into a “release.” By the time the release happens, the developer has changed contexts several times and doesn’t have all of the code changes in mind at the same time. When the release happens, a small problem can turn into a much bigger problem as developers, if they’re even still employed by the company, try to track down and fix problems in code they haven’t seen in months. The result is that project teams go overboard in creating bureaucracy and overhead around releases, with increased costs that are passed on to the customer. In addition, more bugs “squeak through” because so many code changes are happening at the same time, often in overlapping areas, that it’s impractical to find all of the issues.

How to Recognize Effective CD Practices

The premise behind Continuous Delivery is that a developer is most acutely aware of the context of a code change immediately after she has made the change. This is the best time to introduce the code into production. Doing so has several advantages:

  1. The amount of code being introduced is much, much smaller than a large release that has built up over months. The risk of disruption is therefore much smaller.
  2. Because the developer knows that her code is being introduced into production, she will be more focused on quality and will be available at release time in case there are any issues in production.
  3. In the case that there is an issue in production, the developer knows where to go to find and fix the problem because the code is fresh in her mind and the total number of lines of code that have changed are limited.

Kuali developers are distributed across the continent and involved in vastly diverse projects. Our Curriculum Management and Continuity Planning projects started from scratch with Continuous Delivery and Deployment as the default practice. For Kuali Research and Kuali Financials, we’re methodically making incremental changes to enable CD throughout our development teams. Effective CD practices take effort, and the organizational impact can be significant.

Culture. CD requires a different mindset. Engineers must be more accountable. Teams must make time to develop more automation, including automated tests. Engineers need to let go of the fear and embrace the benefits of this new method of delivery. The entire team must be focused on understanding when something is broken and fixing it quickly. We are reinforcing this culture continually within Kuali. We’ve hired full-time experts and brought in additional outside experts to retrain product teams to think about development and deployment differently. Our Wednesday book clubs and coding katas focus on reinforcing tools, techniques and attitudes which foster this culture.

Commitment to Quality. Developers must be committed to quality. CD forces a developer to be accountable for the code that they write. They can no longer write code, throw it over the fence and hope that a QA engineer, a manual tester, or worse, a customer finds the problems for them. Instead, they write the code, they write new automated tests, they run current automated tests, they observe the code in test environments which mimic production and they watch as the code gets incrementally deployed. If problems pop up, they immediately fix them or make the call to rollback to the previous build.

Automated Testing. Automated testing is not a panacea for finding problems, but it goes a long way to helping ascertain the quality of a release. We aggressively add automated testing to our build processes as we introduce new code. The number of tests continue to grow. Automated tests do not replace all manual testing, just repetitive or extremely low level testing. They are most effective when testing the most critical functions, like those which might affect a University’s ability to submit a Research proposal at a deadline.

Fast Build and Rollback. To prevent developers from waiting too long before they oversee their changes moving into production, the process of automatically building and deploying code needs to be very fast. More importantly, the process of rolling back to an old build must also be very fast. Fast rollback helps mitigate risk of disruption when unlikely bugs slip into production. A small issue which might pop up is much less of an issue if it can be reversed in seconds or minutes instead of hours or days.

Change Management. Effective Continuous Delivery ultimately hinges on well-managed Continuous Deployment to customer production environments.  Our teams maintain relationships with customers that allow us to understand their business cycles and workflows. Just because a new feature is in production doesn’t mean the change needs to be live for all users. To minimize disruption, larger changes might be deployed with configuration options that allow the customer to decide when to enable them for users. Smaller updates, like bug fixes or minor enhancements, might show up as soon as they’re available. In addition to these change management strategies, we’re incorporating great Interaction Design, with intuitive helper screens and widgets. These improvements make it easier on the users when new features  are added to existing products, like Kuali Curriculum and Catalog or Kuali Financials.

We are committed to both lowering costs, and enabling customers to more rapidly recognize value with their academic administrative software investments. We’re very confident that with Continuous Delivery and Deployment we are reducing both risk and cost to colleges and universities, while improving our ability to create innovative new solutions and features. Our customers and partners know that the practices that differentiate us from the competition, directly improve their customer and user experience.

Become a partner, not just a customer.
Connect with Kuali