Best match

Most recent

Frontier

The theme of LaunchDarkly’s Galaxy ’23 event is “the next frontier of DevOps,” in which IT and developers still have to stitch together different processes to solve bigger problems, which causes a lot of grunt work and frustration.

https://www.bing.com/th?id=OVFT.uAIZim1ILg4qpxiVzpwMIS&pid=News

New LaunchDarkly features bring its platform to ‘the next frontier of DevOps’

https://www.bing.com/th?id=ODF.aRhHiUGNIxuNRiKFeM1etg&pid=news

SD Times

Kaiser Permanente Foundation Health Plan has reached a settlement with the California Department of Managed Health Care that calls for significant changes to Kaiser’s delivery of behavioral ...

Kaiser ordered to revamp delivery of behavioral health care services

Los Angeles Daily News

Metro Manila (CNN Philippines, October 17) — President Ferdinand Marcos Jr. on Tuesday said his government will continue to support all modernization efforts by the Philippine Coast Guard (PCG).

Marcos vows continuous upgrading of Coast Guard

cnnphilippines

Obstacle

Minister of Cooperative Governance Thembi Nkadimeng says the damaged and ageing infrastructure remains the biggest obstacle to service delivery at a municipal level. Speaking at the ANC’s ...

Nkadimeng: Damaged, ageing infrastructure biggest obstacle to service delivery

Jacaranda FM

Meal

Meal delivery services are super popular (and for good reason). They make whipping up breakfast, lunch, and dinner so much more convenient—especially if you're trying to lose weight. Food is ...

15 Best Meal Delivery Services Of 2023, Tested By Nutritionists And Editors

Women's Health

New Hampshire

Police officer

NASHUA. THIS IS NEXT LEVEL PUBLIC SERVICE. A DELIVERY DRIVER FULFILLED ONE NEW HAMPSHIRE MAN’S DOORDASH ORDER IN A SURPRISING WAY. LAST SUNDAY. DAVID ELDRIDGE FROM BRENTWOOD WAS WAITING FOR HIS ...

Brentwood police officer finishes McDonald's DoorDash delivery after driver pulled over

WMUR

Polynomial expansion

China

The State Post Bureau said the monthly express delivery development index came in at 406.1 in September, up 15 percent year on year. The sub-index for service quality grew 19.9 percent from a year earlier, the sub-index for development scale picked up 12.7 ...

China's express delivery sector registers expansion in September

Big News Network.com

As I sat down to watch my favourite channel Bloomberg, a breaking news of theirs caught my attention. And it was Delivery Hero in talks to sell Foodpanda in some Asian markets. It heightened my curiosity because I know they are the owners of a popular food ...

Service delivery

business

Get the most recent info and news about LaunchDarkly on HackerNoon, where 10k+ technologists publish stories for 4M+ monthly readers.

LaunchDarkly is a continuous delivery platform that provides feature flags as a service and allows developers to iterate quickly and safely. LaunchDarkly gives you the power to separate feature rollout from code deployment and manage feature flags at scale.

LaunchDarkly

Use LaunchDarkly to Quickly Implement Feature Flags

We've all been there. You're pushing to main, something you've done hundreds of times before, and by the time you go to refresh your production environment, you notice something's wrong. When you take down prod, the point at which you see is already too late. Your name is on the deployment, the issue is live, and the clock is ticking. So what happens now? The first thing to do is understand where you've gone wrong. Use the diff command to highlight the code that's changed without relying on your own eyes to spot the change. We can sometimes become so accustomed to the way we write our functions that a breaking change will be practically invisible. Remember those recent additions like git switch and restore are there to make your life easier and help you triage while looking for a fix. Next, you need to accept that it might not just be the code. It might, in fact, be a combination of your environment, your infrastructure, and the combination of all three being stress-tested by particularly unusual behaviour. Don't assume that you can handle this on your own. Simply rolling back your change may not work. Contact DevOps. It's always better to ensure that the people who need to know about a worst-case scenario are alerted if there's even a remote chance it could be in effect. The most important thing to remember is that this happens to nearly every engineer—no matter their status or tenure, no one is immune to taking down production. Whether you're joining a new engineering team or embarking on a new stage of a product's life cycle, the likelihood of you breaking production is rarely a case of if. More often than not, bringing down production is closer to a matter of when. Case in point, earlier this year, surprised its with . While this example is one of the more achingly public displays of what happens when your production build goes awry, given enough honest discussions and code reviews, a forensic investigation would undoubtedly uncover countless instances of these occurrences happening. HBO Max 44 million-strong user base an integration test email that went to everyone One of the most reassuring principles of software development is that you can usually count on the task you're trying to accomplish having been performed by someone else. This goes for both the good and the bad. Whatever the dilemma, you can almost guarantee someone out there is experiencing a scar-tingling Harry Potter-esque flashback on your behalf. Here's how not to do it again. Set the stage for rehearsals When you're running a race, you want the conditions to be right: not too hot, a manageable incline, and most importantly, an easy-to-follow route. The same goes for your training runs. You ideally want to be stress-testing yourself under conditions that prepare you for the final event. This analogy couldn't ring truer for your development environments. If your change is going to break in production, it needs to break in staging first. Best practice dictates that staging should mirror production. As programmer and writer notes in her : Alice Goldfuss article on the best practices for staging Staging is where you validate the known-unknowns of your systems. It's where you can get the chance to stress-test your build and see how your dependencies hold up under a feasible amount of pressure. Try to resist the temptation to make things easy for yourself in staging, and ignore the idea that all staging environments need to be identical. While recently serving as the Director of Engineering at Nordstrom, Josh Maletz, , maintains a myriad of environments, stating, "we have staging environments for 20-year-old monolithic applications with hard-wired dependencies to vendor test environments. We also have serverless applications with infrastructure-as-code deployed to the cloud where we employ robust service virtualization techniques to exercise our system against simulated erratic behaviour." The critical factor is that your staging environment is fit for purpose rather than fitting a uniform specification. when discussing his team's approach Gather an audience Access management gets overlooked as a vital component of the process here. Senior Developer, Victor Guzman, that in one of his instances of an unintentional push to production, the event didn't result in any breaks per se. noted in his DEV Community series on developer fears Still, it did highlight that there was no policy around access management. This wouldn't have happened without someone initiating the difficult conversation around what went wrong. To improve, we need to be open to having an honest, blame-free post-mortem. Ultimately, when it comes down to it, one person shouldn't be able to break production. Sometimes the question shouldn't sit at whether or not you should make that change, but rather should you be able to make that change. It can be far too tempting to hide your work, especially when things go wrong. The immediate urge is often to bury your mistakes and pretend that they never happened. This is great for the ego but terrible for personal growth. We earn our stripes through understanding what not to do and the most valuable lessons to learn come with a chaser of pain. As mortifying as it is, we've got to learn to wear our errors like badges of honor. But outside involvement isn't only beneficial from a learning perspective; it also enhances the efficacy of your testing procedures. When it comes down to it, oftentimes, the people writing the tests want them to pass. As , your test suite should include the following types of tests in a pre-production environment before releasing new features: my excellent colleague, Heidi Waterhouse, notes Unit tests to check the smallest unit of code that can be logically isolated. Integration tests to test software dependencies and the combination of various software modules. Performance testing which includes load tests and stress tests to identify how a system or software behaves when there are spikes in production traffic. Regression tests to confirm previous functionality continues to operate as expected. Functional tests to confirm the feature performs or functions as expected. Lint tests to check your source code for programmatic or stylistic errors. Usability tests to validate the ease of use with end-users. While we can strive to create the best possible environments for staging, no traffic synthesizer will truly be able to replicate the stresses of production. Testing in production is necessary to make sure what you're building will actually hold up when in the wild. Wrapping your change in a feature flag is one of the safest ways to ensure that you've got overall control over what you deploy in production. Once you're confident that your changes won't break and your tests are passing, you can roll out your feature more widely, safe in the knowledge that you'll always have an off-switch. If you've got stories of your experience with testing in production or perhaps can talk about the challenges that impact your DevOps and SRE teams, then we'd love to hear from you. Our third annual conference, Trajectory , takes place November 9-10, 2021. The CFP ends this week, closing on Monday 9th August, so stay tuned for our full line-up of speakers later this month. Author: Jessica Cregg, Developer Advocate Jessica is a Developer Advocate at LaunchDarkly where she speaks about change and writes about the human implications of engineering decisions. She also writes for a selection of tech publications and works with Coding Black Females to improve equal and equitable representation within the technology industry.

So You Took Down Production - Now What?

373 Stories To Learn About Learning To Code

166 Stories To Learn About Devops Tools

HackerNoon’s Startups of the Year is back and it is bigger, better, and more beautiful than ever! The AD slots are prime rib, the pages have been max-SEO-optimized, and more than 50,000 startups across 4200+ cities will activate their marketing machineries to become the best startup in their backyards. were Brex, Udacity, Udemy, Vercel, LaunchDarkly, FreeCodeCamp, and others. Sponsors in the previous iteration We had quoted around 200,000 impressions but... we ended up smashing past those numbers by over 150%... And now we’re back to make this even bigger. and winners will be tabulated and announced at year-end. This year, Startups of the Year will run for the entirety of 2023 (instead of 4 months as was done previously), Sponsors (who commit now) will get placements on: Home Page 🌐 Region Page 🌎 (your choice out of 6 continents) Atop Every City Page in Your Region 🏙️ Massive Banner + CTA under voting panel 🚀 Dedicated Newsletters 📰 Dedicated Announcement Posts on HackerNoon 📢 Shoutouts in Press Releases 🗞️ Auto-Embedding in social post ‘shares’ 🤖 Targeted Social Media activities and promotions 🎯 If you’re still on the fence, this might do the trick. knockout mock-up of the San Francisco page before your competitors hear about this offer ‘on the grapevine’. Book a meeting with us to discuss numbers and lock your spot

Startups of the Year 2023: Lock-In All-Year Long Advertising at < $1 CPM

Startups del año 2023: publicidad fija durante todo el año a menos de $1 CPM

Startups de l'année 2023 : publicité verrouillée toute l'année à un CPM inférieur à 1 USD

स्टार्टअप ऑफ़ द ईयर 2023: लॉक-इन ऑल-ईयर लॉन्ग एडवरटाइजिंग at <$1 CPM

2023 年のスタートアップ: 1 ドル未満のインプレッション単価で通年広告をロックイン

Startups do ano de 2023: publicidade fixa durante todo o ano com CPM inferior a US$ 1

Công ty khởi nghiệp của năm 2023: Quảng cáo cố định trong cả năm ở mức < $1 CPM

2023 年度初创企业：全年锁定每千次展示费用低于 1 美元的广告

When thinking about handling PII (Personally Identifiable Information) for SaaS companies, standards like SOC 2 compliance and GDPR immediately come to mind. One of the most sensitive types of information for a tech company to handle, however, is actually PHI, or protected health information. To be able to handle this type of data, a company must become HIPAA compliant. HIPAA, or the Health Insurance Portability and Accountability Act, regulates the way PHI is collected, processed, stored, and shared in the United States. Protecting PII remains as important as ever to maintain a person’s security and privacy online, but in addition, the improper handling of a person’s health data can actually be dangerous. For example, data concerning a child’s vaccinations that are improperly stored could cause the patient to receive a double dose, no dose at all, or the incorrect vaccine entirely. Today, we are excited to announce that Courier is now HIPAA compliant and this post will get into why SaaS companies should be HIPAA compliant, why this is important for our company, and the steps we took to get here. Why SaaS companies should be HIPAA compliant 2020 introduced us to healthcare complexities the likes of which the vast majority of people had never seen within their lifetimes. While the world has experienced health emergencies before, none of this size have landed in our current era of tech expansion. We now have SaaS tech tools to help healthcare providers organize and digitize to provide a higher quality experience for patients, both in-person and online. Even mental health services are now often provided at high volume and quality through online counseling options like . BetterHelp With the demand for healthcare tech growing and the digitization of medical care expanding, even existing SaaS companies can expect a greater portion of their customer base to deal with PHI, which means that they themselves will need to be equipped to handle this sensitive data. Becoming HIPAA compliant is therefore likely going to be necessary in the near future, if it isn’t already, for many SaaS companies. Why Courier invested in HIPAA compliance Here at Courier, in particular, we knew from the start that HIPAA compliance would be necessary sooner than later. Courier’s mission is to make software-to-human communication delightful, currently by providing excellent notification infrastructure. We are happy to work with our current set of customers such as to provide better communication between guests and hosts and to help retain users. Another line of important communication, however, exists between healthcare providers and patients, or with other providers. Hospitable LaunchDarkly A patient who could receive notifications about blood test results, for example, could access their data more easily through a HIPAA-compliant Courier instead of having to deal with terrible UX to get the information they would be waiting for. Other notifications that would require HIPAA compliance include reminders for doctor’s appointments, flags that prescriptions are ready for pickup, and as a more timely example, notifications for Covid test results. Courier’s journey to compliance To become HIPAA compliant, we had to consider two major parts of the process of handling PHI: who all will be touching the data and how it will be presented in the product. For any technical product, data must go through several touchpoints, often repeatedly. PHI collected from a user, for example, would reach our sub-processors in addition to our own databases along with those of our customers who are collecting the data itself. To maintain the integrity of HIPAA as this data moves around, every organization involved signs a BAA, or Business Associate Agreement. According to the U.S. Department of Health & Human Services, a business associate is any person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity. For Courier, this includes all our vendors, including AWS, for example. In terms of how PHI would be presented in the product, we thought about this as an engineering issue from the start. HIPAA applies to communication just like stored data and by nature of how Courier works, that means that the amount of PHI stored for a particular user will only increase rapidly over time. This means that the way data is accessed needs to be considered while designing the product itself. As an example, employees of Courier’s customer companies can generally see logs of notifications with their end users to help them gather data to improve their notification strategy over time. However, if a Courier customer is HIPAA compliant, their employees should not have access to their end users’ PII. In this situation, Courier must provide customers with the right tools to manage which employees can access which types of data. This is something to consider particularly carefully if you are an engineer at a SaaS company who is building a notification infrastructure in-house instead of using a tool like Courier - the complexity of building the infrastructure compounded with figuring out how to handle the data in a way that would be HIPAA compliant would be a massive undertaking that is best mitigated by early design considerations around data collection and logging. As the engineering team hammered out the best way to handle how the data is compiled and logged, we also needed to make sure to have internal policies designated around PHI as well as processes to implement security safeguards, conduct risk assessments, and handle documentation. Conclusion After this full process, we are happy to announce that Courier is now fully HIPAA compliant, which applies to all U.S. PHI. To learn more about how Courier approaches security, check out this . If you’re looking for HIPAA-compliant notification infrastructure for your own organization, . series of articles check out Courier here

Courier's Journey to Becoming HIPAA-Compliant

We’re excited to announce that we’ve raised $35M to provide engineering teams with fantastic notification infrastructure! The round was led by GV with participation from our existing investors at Bessemer Venture Partners and Matrix Partners. - Sangen Zeb, GV “Courier is building the future of notification infrastructure. The company has a fast-growing set of customers with a need to provide the best possible notification experience. GV is thrilled to lead Courier's Series B and partner with Troy Goode and the entire executive team as they deliver on an unparalleled approach to software notifications." Courier’s vision is to be a single source of truth for all of the end-user’s notifications. We aim to bring together all notifications, whether they may be from mobile, email, Slack, or any other channel, to a single point of easy access to lift the burden of improving the notification experience from the end-user. The next incremental step on this road is to begin to improve mobile notifications. According to a Courier survey of 157 notification recipients, respondents are more likely to engage with a smartphone notification than a text, email, push, or in-app notification. Our first goal for our Series B, therefore, is to improve the user experience of mobile notifications and we are starting down this path today by announcing new advanced mobile notification capabilities for our platform. Check out the video below to learn more about our new mobile offerings! https://www.youtube.com/watch?v=tPB2wFI7u0I A new category of software: Notification Infrastructure Every piece of software in the world sends notifications, and just about every software team has had to build the infrastructure needed to deliver those notifications in-house. This ubiquitous need for notification infrastructure demands its own category of software, which gives developers the option to use a third-party API instead of building an entirely new notification system from scratch. As a former engineer and engineering executive, I’ve experienced the pain involved with building and scaling notification infrastructure too many times. Every time I was tasked with building a new notification system for a new product, I wished there was a service I could reach for to free up my engineering team and avoid the future headache that I knew would follow. The lack of this type of solution is what drove me to found Courier. Courier delivers notification infrastructure to our customers as SaaS. At the center of our product is an API designed for engineering teams. This API allows developers to send notifications across any channel as well as manage user data, preferences, notification workflows, and more. In addition to the API, we provide a web Studio that allows our customers to easily design omni-channel notifications, view logs across notification channels, and providers, as well as visually build out notification workflows. We’ve come a long way over the last three years, both as a company and a product, thanks in large part to our customers. Courier is used by hundreds of fantastic software companies such as New Relic, LaunchDarkly, Lattice, and Uservoice. These companies have partnered with Courier to deliver a better product experience to their users while dramatically reducing the amount of time and money spent on building and maintaining their own internal notification infrastructure. - Eric Koslow, CEO, Lattice “Before Courier, we were spending tons of time integrating with every delivery platform every time a customer requested a new connection from us. But now it’s as easy as making an API call. So, so excited about this launch. Huge congratulations to the Courier team!” What’s next: notifications that delight, not distract Product notifications are one of the rare parts of software that affect nearly everyone on earth. If you use the internet for work, to buy flights, to network, or to do just about anything else, you receive notifications from that software. At their worst, product notifications are annoying, distracting, and anxiety inducing. They can come through different channels from text to email to mobile notifications - or from all of them at the same time, acting as a constant disrupter in the user’s life. At their best, product notifications deliver a delightful experience and make sure that we’re aware of key events that might help catch a flight, meet a deadline at work, or connect with a loved one. In other words, they provide useful interruptions that improve the user’s life. We will use this new capital to continue to invest in our core mission of making all product notifications delightful, starting now with mobile. What that means today is delivering an amazing toolset to the builders, product, and engineering teams, who are in charge of developing product notification systems for their apps. We believe that just about everyone in these roles wants to deliver great notifications with an excellent user experience and that the better the tools and resources at their disposal are, the more able they will be to accomplish this. Introducing Courier’s new mobile capabilities Today, we’re announcing a new set of two tools and resources for product builders to deliver delightful notifications for their mobile applications. Mobile notifications are the most ubiquitous type of notifications and the one with the most potential to annoy users. One annoying notification experience can result in a user turning off notifications altogether, which greatly reduces both the utility and engagement of any mobile application. The first is our new mobile SDK. This SDK makes it easier for developers to manage push tokens across devices and operating systems. This gives developers better control and visibility, making it easy for them to deliver a more consistent and customized experience for their users based on the best way to reach and engage their users for their specific app. Here’s an example: // Register multiple devices for a given user. Notifications will be delivered to each 
// device in a single send call.

{
  "tokens": [
    {
      "token": "abc123",
      "provider_key": "apn",
      "properties": {
        "test": true
      },
      "device": {
        "app_id": "com.my.app",
        "platform": "iOS",
        "model": "iPhone 13"
      }
    },
    {
      "token": "cba321",
      "provider_key": "firebase-fcm",
      "tracking": {
        "ip": "127.0.0.1",
        "lat": "0.0",
        "long": "123"
      }
    }
  ]
} Visit this page to learn more about this new mobile functionality and request a demo and check out this video of me demoing them below. Conclusion: The work is just beginning Our mission to make notifications delightful is a big one and there’s still a ton of work to do. We could not have made it to where we are today without all of our fantastic customers, New Relic, LaunchDarkly, Lattice, Color Health, and many others who share our belief in the value of delivering a great product notification experience. This new funding presents a great opportunity to achieve this ultimate goal. Get a demo to learn more about Courier’s goals for mobile notifications! here If you are interested in helping to build the future of notification technology starting with mobile channels, we are ! hiring

Courier Raised a $35M Series B to Make Notifications Delightful

Q: What is your official role at KB? A: My official role is Head of Development, COE (center of expertise) at Komerční banka. Q: What exactly is your area of responsibility and day-to-day? A: As the Development COE lead, I consider the expertise, structure and capabilities needed to make software development successful across hundreds of developers. We have roughly 600 people in the broader development team, but I’m not directly responsible for managing them. I’m responsible for defining how they will do their job. So for development best practices, standards unification and so on. Q: What’s your main focus today at KB? A: Our transformation project. We have the current bank, which is built on typical legacy banking systems…basically huge, distributed monolithic architecture systems. That is where most of our developers (around 400) are working day-to-day as it generates the bulk of the revenue for the bank. Alongside the legacy applications, we decided to completely modernize to something that we call “Digital Hub” which is replacing the bank’s current infrastructure. The front-end applications are native mobile and web applications. The Digital Hub and new front-end applications are built entirely on microservices so we have to redesign a lot of things and introduce new guidelines for people. All of this together is what we call the “New Digital Bank”. It’s a massive project! Q: Does this transformation stop at some point? A: Great question. We think about the transformation in two main parts: “The New Digital Bank” initiative is planned for 5 years and we are about 2 ½ years into it already. It started small with a few teams that were ready to adopt the most modern development approaches and it’s growing every year. Today we have about 180 engineers split among 50 teams. Those teams have been hired externally or transferred over from the legacy systems. They are dedicated 100% to “The New Bank” effort. The other side is culture transformation. We call this “Agile 2.0” which hits the whole team (both legacy systems and new systems teams). Adopting Agile and DevOps is all about adopting a new way of working. This shift is something that we are driving with our legacy system teams as well. While the building will come to an end at some point, the hope is that the new culture will take hold and be the new way of working at KB. Q: Beyond agile, have you adopted any new approaches? A: Yes, there are three new approaches that we adopted: Moving to OKRs which aligns well to agile. Adoption of Microsoft Teams in all of our meetings which has helped with remote work during the COVID pandemic. The last has been adopting ‘the Spotify model’. I don’t know why, but it’s pretty popular in Czech Republic. The biggest thing that resonated with us is that you have functional “tribes” that contain the people and skills that the “tribe” needs to develop and run their own projects or their own applications. This aligns well to the microservice architecture that we are moving towards. Q: What about tooling, languages and infrastructure? How do you manage that across so many people and teams? A: As the COE, we are mostly responsible for the unification of how people work. We are pretty rigorous in this. We developed our own KB framework, which we call Speed which is divided into three parts: First is a Java SDK, built on top of Spring Boot, which is a framework for building cloud applications. CI/CD Pipelines to automate deployment. This is built on Jenkins and Argo CD. Kubernetes, where we are deploying and running our applications. We built our own cloud infrastructure, so everything needs to be on-premise today. If a team needs something, they need to ask for it and it is reviewed by my team. If we have something that solves their problem, then we ask them to use that. If not, I’m open to adopting a new technology. Q: Is that an evolving system that changes as you go? A: Yes exactly. We started with the Speed Framework two or three years ago and it is still evolving. The first version was built for monolithic applications and monolithic works. We are on version 4 now. The microservice approach was implemented in version 3. The disadvantage is that we have to follow some product updates and life cycles which is really painful for us. Kubernetes, for example, has three major versions per year. We are now facing the situation that the upgrade pains hurt as it takes a few days each time. Going forward we want to make it more independent of these cycles and automate upgrades in the future. Interestingly, our parent company adopted OpenShift which is something we are keeping an eye on. We’ll see if we unify the frameworks or not in the future. Q: Sounds like you are using a lot of open source technologies in the new platform, have you always done that? A: No, we used a lot of the typical products like Oracle, Sun Microsystems and IBM. For the new digital bank we decided to adopt more Open Source technologies like Kafka, Flagsmith and ElasticSearch, which is great because they are free, but we are responsible for keeping it up and running. This is a completely new mindset for teams. Q: Did you have to fight to use those products internally? A: No, they sort of just accepted that because they know the reasons. If we show them the contract with Oracle, how expensive it is, there’s a big business case to adopt open source. Even if you have to have a few more people to manage the infrastructure it has a positive impact on our costs. Q: What about feature flags, was that something that you knew you needed before you started? A: That’s a good question because, you know, even in current banks (legacy systems), people are using feature flags, but they’ve developed their own systems. They’re very simple systems that manage the configuration file for example. And it was just because the legacy system was only deployed 3 times per year. So you can imagine how difficult it was to keep all of the promises from other teams. So they were really just there to keep the enterprise release management and testing on time and coordinated. It was easy to switch “on” or switch “off” some features that were not ready for the deployment. But for the New Digital Bank we have microservices and continuous integration. We deploy on a daily basis to non-production environments. Interestingly, we only have two non-production environments. One of them is only for testing during the build and the other is the final non-production environment (AKA staging). Q: Was it a conscious decision to have fewer environments? A: Yes. This is an approach that I brought to the bank where we completely redesigned some environments and how we deploy to them. The goal is to get to production as fast as possible in order to keep production and non-production as close as possible. Q: That’s interesting…for some of our customers the holy grail is to only have one environment, just production, but that’s probably impossible in your business, right? A: Yeah, that’s impossible. There’s a lot of regulations. For example, a lot of developers can’t access the production environment. I have some experience with that where you just test everything in production. For example, one regulation says that you can’t even have a testing account in production because you are operating with real money. Everything must be “real” in production. Despite the regulations, I still wanted to have the smallest number of non-production environments as possible. Q: So when you were selecting a feature flagging system, did you consider SaaS services or was that something that you immediately ruled? A: Yeah, we decided to evaluate 3 systems; Flagsmith, your competitor LaunchDarkly and considered building it ourselves. We did three “proof of concepts”. First was with LaunchDarkly, then Flagsmith and then we looked at our own homebuilt system. We decided on Flagsmith not just because of the system’s flexibility, but also the great support, the fact that you guys are open source and the great documentation. Q: How are things going today with feature flags? A: We have been using feature flags for one year in our non-production environments which has been working great. As for the production environment, it took a while from a security perspective to implement feature flags in our production environment. The reason it took so long is because the person originally responsible for bringing feature flags to KB left. Then the security team changed their criteria for evaluation and then finally on the third time, we got it into production after passing all of the penetration testing and requirements! Q: Wow! Making changes at a bank is not for the faint of heart! A: Yes, because of the security standards the entire banking industry is really sensitive to this. Now we are up and running and focusing on the permission models and logging everything so it is auditable. Q: Has it changed your workflow at all? A: Yeah! We decided to start with the front-end, especially mobile teams. People have been waiting for this capability because they’ve used feature flags in previous roles. We have people on the team pushing to adopt because without a feature flag system, everything has to wait until it is fully finished. Now they can deploy to production and more and more teams are onboarding to The New Bank. For those teams in a microservice set-up, it is crucial for teams to be more independent. So far, we have about 85 engineers working with Flagsmith in production. That is almost half of The New Digital Bank already! Q: Are you using flags on server-side as well or just the front-end? A: So far just on the front-end, but we are getting ready to roll that out with the backend systems that leverage microservices. That will be very soon! Q: Any ways that you want to use Flagsmith in the future? A: Yes. We are looking at integrating the Flagsmith API into JIRA and being able to drive things upstream and be able to keep the QA teams aligned with the product owners. Q: Oh great! We are actually working on something similar at the moment. We’d love to show you guys and get some feedback. Well thanks so much for being a customer and for taking time to connect with us today! We really appreciate it.

LaunchDarkly

launchdarkly.com

351 employees

Since 2014

COMPANY RANKING

LaunchDarkly

EVERGREEN INDEX #2758

See more notable links about LaunchDarkly

Apply to get your Tech Company News Page live on HackerNoon.com today!

Read More Tech Stories Related to #LaunchDarkly

LaunchDarkly

LaunchDarkly

launchdarkly.com

351 employees

Since 2014

COMPANY RANKING

LaunchDarkly

EVERGREEN INDEX #2758

Related CompaniesRank

LaunchDarkly Story MentionsComplete List

See more notable links about LaunchDarkly

Apply to get your Tech Company News Page live on HackerNoon.com today!

Read More Tech Stories Related to #LaunchDarkly

LaunchDarkly