devopsy.kinsta.cloud

Tag: feature rollouts

  • CloudBees Brings Feature Flagging to On-Prem Environs

    CloudBees Brings Feature Flagging to On-Prem Environs

    CloudBees this week announced an update to CloudBees Feature Flags that now makes it possible to deploy this capability in on-premises IT environments.

    Moritz Plassnig, senior vice president and general manager for software delivery management and software delivery automation cloud at CloudBees, said CloudBees Feature Flags previously was available only as a software-as-a-service (SaaS) application following the company’s acquisition of Rollout last year.

    However, there are still many organizations in highly regulated industries that are prohibited from developing applications in the cloud. The latest version now allows those organizations to employ CloudBees Feature Flags to roll out new features in a more controlled way, he said.

    Cloud computing, of course, has been around for more than a decade. The adoption of cloud computing has increased dramatically in recent years; however, the bulk of applications are still deployed in on-premises IT environments. CloudBees makes on-premises editions of its platforms available alongside cloud services to meet IT teams wherever they are on the application development spectrum, said Plassnig.

    While feature flagging has been around for some time most enterprise IT organizations are just now starting to employ it. As organizations roll out new capabilities, feature flagging enables DevOps teams to make a new capability available to only a small segment of application users. Assuming all goes well, the DevOps teams can then go ahead make that capability available to all users with greater confidence. Feature flagging makes deploying updates to applications less scary for all concerned by reducing the inherent risks, Plassnig noted.

    Feature flagging is used mainly within the context of application development. However, Plassnig said eventually this capability will be deployed more widely in production environments. Organizations, for example, might employ feature flagging to make specific capabilities available to specific classes of users.

    Of course, CloudBees is not the only provider of a DevOps platform to embrace feature flagging. However, as the provider of an enterprise edition of one of the most widely employed continuous integration/continuous delivery (CI/CD) platforms, CloudBees is betting it’s in a better position to make feature flagging a standard capability within any software development life cycle (SDLC). Plassnig said DevOps teams should also expect to see CloudBees tighten the integration between CloudBees Feature Flags and CloudBees Flow, a tool for orchestrating releases and automating application deployments.

    With the rise of microservices, it’s become easier for DevOps teams to isolate functions within applications. The challenge is that managing all those modules of code often requires DevOps teams to implement more complex workflow processes. Advances in automation will simplify those processes; nevertheless, DevOps teams still have to define the workflow processes that will be automated.

    In the meantime, it’s only a matter of time before DevOps teams come to view feature flagging as a standard requirement. It will be interesting to see to what degree feature flagging might one day be incorporated into the core open source CI/CD platform itself.

  • DevOps: Get the Basics Right to Avoid Costly Mistakes

    DevOps: Get the Basics Right to Avoid Costly Mistakes

    It is a truth of both agile and DevOps that speed is of the essence. This is a relative statement—some apps/portfolios/orgs envision speed completely differently than others—but if you are releasing more frequently than you were in the past, thanks to DevOps, that’s kind of the point.

    Yet, we see a whole selection of things that fall by the wayside or are underserved. Security and testing are the easy/obvious ones. Considering the frequency with which we see “Unsecured Amazon storage bucket” (one announcement of this type spurred this blog), should we not see this folded into standard procedure or tools? Well, it is folded into standard tools for checking your cloud environment—I’ve used a couple of them and seen this warning come up. So shouldn’t organizations be using these tools more?

    One thing about speed: It tends to cut corners. And cut corners lead to lapses. You can be a blameless environment that doesn’t punish people for mistakes, but for an organization, a mistake such as exposing hundreds of thousands of users will be punished from the outside, from regulatory agencies and the market in general. They’re not mistakes we should be making, and yet it still happens.

    Another one is rollback versus roll forward. Most DevOps shops focus on the ability to fix an issue and plow forward. This works really well, 90+% of the time, and fails spectacularly sometimes. While it is an added step with some slowing of process, being able to roll back changes is important. And more than, “Well, theoretically, Git will allow us to go back to the last marked release …” because there is far more to an application architecture than just the source stored in a repository.

    In short, no matter how fast things are going, have a plan for when things go wrong. Because they inevitably will. And take the little bit of extra time for preventatives such as warning someone other than the creator about buckets with no security.

    “But there isn’t time …” is the common refrain to blogs such as this one. I get it. The increase in delivery only creates an increased appetite for delivery. But is there time to respond to disaster, should the worst happen? And I’d argue that it must be IT that plans for disasters. When someone gets fired because there was a security breach or a total systems failure, it is rarely an app owner. That puts the responsibility to make certain one doesn’t happen squarely on IT.

    We’re delivering faster, offering increased functionality to users, moving forward on every front. You all are out there rocking it daily. Don’t risk all of that being ignored because you failed to take care of basic issues. Check out the tools to help out; feature flags and cloud security scanners both spring to mind with regard to my examples above. The tools are out there, you just have to work them into your process.

    — Don Macvittie

  • Split Software Adds Feature Monitoring to Feature Delivery Toolset

    Split Software Adds Feature Monitoring to Feature Delivery Toolset

    One of the issues that has long plagued both development and test is determining exactly where problem code exists. The increasing rate of change that agile and DevOps have brought to projects makes this problem worse than ever because changes today can impact code from yesterday–or yesteryear.

    The constant flux that modern software is in makes tracking down issues that much harder. This is offset a little bit by the fact that changes are generally smaller and more incremental because there are several iterations to get improvements into place and short sprints are the norm. But not completely offset, because a defect may just now be showing up, even if it was introduced several iterations ago.

    Feature Delivery tools offer the ability to group changes into features, then turn them on and off as needed. In the case of Split, they can also be phased in to see impact upon users. While the name uses “feature”, any code change like “feature enhancement” is included.

    The announcement pertains to new functionality called Feature Monitoring. This new addition to the toolset allows monitoring of features in production to show the DevOps team what is happening with their changes in real time. It also allows for advanced targeting of users so small groups can get the updates and evaluations made on how the changes impact those users in production.

    Feature monitoring captures error data, and feature tagging ties that data to features, meaning defect identification and resolution can both happen at a faster pace. Less looking where there isn’t a problem, and more information about how buggy a new release is.

    Given that I’ve recently written a fair amount about testing and the issues test DevOps team members face with rate of change, this seems custom-designed to address those issues. While there is no silver bullet, the faster issues can be identified, assigned and repaired, the better the overall application quality will be–and that is what this announcement is about.

    Not having used the tools yet, I can imagine some thought has to go into inter-related functionality, but that has always been true–you have to know what works as an overall system and can be placed together in a release versus what has to be held back if a given piece is incomplete. The way I envision Feature Delivery, and more specifically Feature Monitoring, being used would be smaller pieces than an entire release. Even if a new feature is going live, someone knows what inter-related pieces must be complete, so simply shifting that knowledge left will allow effective feature tagging.

    Finally, the ability to turn updates on and off by changing flags means less downtime, and if planning is done well, the virtual or complete elimination of rollback plans. Agile and DevOps talk of fix and re-release, but we’ve all seen scenarios where that simply isn’t an option, and this may be the solution we’ve been looking for–rollback by changing a flag that changes what code is executed. Flag-checking occurs in code with if-then’s though, so after many iterations code clean-up, it would likely need to be done just to keep the code from being overburdened with nested logic for iterations that are known to be stable.

    I think I’ll add this to my list of markets/products to dig deeper into and actually put to the test. We have a set of servers sitting idle at the moment, and a mobile app we use for testing, perhaps we’ll take some time to test out flagging and nesting.

    In the meantime, it is definitely worth a look. Anything that eases test burden and might remove the need for rollback planning is worth a look. Meanwhile, keep kicking out the tools that run business.

    — Don Macvittie

  • Feature Flagging Poised for Wider Adoption

    Feature Flagging Poised for Wider Adoption

    Feature flags, also known as feature toggles, provide a means for DevOps teams to test and add new capabilities to their applications without having to take the entire application offline. The downside is they generally result in more branches of applications that need to be carefully managed within the context of a DevOps process.

    A recent survey of 550 software developers and decision-makers conducted by the market research firm Vanson Bourne on behalf of Atlassian and Rollout.io, a provider of a platform for managing feature flags, suggests that IT organizations are getting more comfortable with managing feature flags.

    The survey finds 95 percent of survey respondents said their organizations have implemented, have begun implementing or plan to implement features flags. Those that have implemented feature flags said they add 30 new features on average to each application per year, compared to those that have only begun implementing (21) or plan to implement (18) them. A full 81 percent said use of feature flags will increase over the next 12 months, and 88 percent said modern software development should assume to include feature flagging.

    The primary driver for implementing feature flags are a need to reduce risk (46 percent), increase speed of development (46 percent) and increase speed of deployment (45 percent). Eighty-seven percent of respondents said enabling an on/off or “kill” switch for features also reduces the risk of application downtime for customers.

    A total of 97 percent of respondents said they are under pressure implement new application features faster, and yet 65 percent said it is difficult to accomplish that goal safely. More than 61 percent of respondents said their organization releases new versions or updates for applications once a week or more. However, 72 percent admitted they have lost customers or users due to application development errors.

    Rollout COO Ronit Belson said building out the functions required to manage feature flags doesn’t make much sense when platforms such as Rollout.io are now emerging. The survey finds nearly 90 percent of respondents who have implemented feature flags in-house would consider moving to a third-party supplier for feature flagging management software. A total of 37 percent of respondents said the cost of in-house development is higher and 32 percent said they encountered more complexity than anticipated.

    Belson added most organizations not only fail to appreciate the cost of implementing feature flagging on their own, but also the impact feature flagging has on the culture of the IT department.

    Thanks to the rise of microservices, feature flagging should become more prevalent as monolithic applications give way to a more granular approach to application development that makes it easier to isolate functionality. In fact, the ability to apply feature flagging might be considered one of the primary benefits of the agility inherent to any microservices architecture, especially it if relies on containers that can be easily ripped and replaced. The challenge organizations will face is implementing the DevOps processes required to embrace feature flagging at scale.

    — Mike Vizard