Deploying our service is a grudge match between customer benefits and customer pain. In one corner, rolling out fixes (yay!) and delivering new features (double yay!). In the other corner, training on new features (boo – sounds like work), and change management processes (more work).
We put a great deal of effort into optimizing these processes, so it’s important to share how we think through these optimizations. For now, I’ll narrow focus on the issue-fix aspect of the deployment process, and in later blogs I’ll cover new feature delivery.
The fine printBefore I start, a quick disclaimer: what I’m about to describe is subject to change. We’ve been a fanatical agile shop for nearly seven years and we believe change is an important principle of the agile approach. So, if you’re reading this in 2017 or later, please understand that we might have tweaked some of these details. OK, now for the good stuff…
You might not be surprised to hear that bugs are occasionally found in our service (I know, the horror!). Nobody likes bugs, so we need to address them as soon as possible. And because our service uses a number of telecommunication providers to make text messages flong (on my iPhone, anyway), phones ring, and other third-party communication channels do their thing, managing the infrastructure related to these providers requires constant effort. In short, we need to be able to release and deploy fixes FAST.
Keep those cards and letters coming
It also might not surprise you to hear that our customers ask for new features (the audacity!). From July 1st to Sept 30th, we received 133 service enhancement requests – that’s 2+ per business day. The product managers who handle these requests interpret them into new features and then work with our engineers to build them.
So far, so good – and in theory we should be getting these features into your hands ASAP. But these features are product changes: while the customers who asked for a change are willing to take on any additional testing and training work to get their new features, customers who don’t intend to use the new features don’t want that burden imposed on them. That means we need a process that doesn’t force new features on customers too quickly.
Balancing the need for speed
Okay, so we can probably agree we want fixes fast and features not too fast – how can we possibly strike this balance?
First, by using deployment speed: we deploy at least weekly, if not more frequently. Our core sprint work uses a continuous delivery process which we deploy on a weekly schedule so that we can seamlessly deliver non-critical fixes at that cadence. We can also generate and deploy critical fixes in between these weekly deployments as necessary to address issues like zero-day vulnerabilities.
Second, by using feature flags: deployments include the latest feature developments, but some features are not quite ready for your use after just one sprint. And as previously mentioned, your user base might be confused if new buttons and features show up every week. So we use feature flags/toggles on our new features so that we can conditionally turn them on when we’re ready to release them. That allows the new fixes to get out the door without having new features show up. (We’ll talk more about feature flags in another blog, but those of you who are new to xMatters might want to check out our Early Access Program if you want to play with new features faster).
Third, through thoughtful communication: because fixes can cause behavior changes in the system, we have implemented a new communication process to advertise the parts of the service we worked on so customers can keep an eye out for any unexpected behavior. Our support notes are designed to provide this information (here’s a sample from the deployments leading up to our Rogue release). Those notes work in conjunction with the scheduled maintenance posts on our status page to ensure this information is delivered by the latest technologies.
Using these three mechanisms, we can offer the best mix of quick fixes – without forcing training and change management on our customers.
Bada platform is becoming more and more famous this days and people talking about same. Some friends included those who have bada OS mobile asked me "what is bada?"and "what its features?". That encouraged me to research and write this article.
[step="" title="What is BADA :"]
The word BADA is derived from a Korean word it means ocean seashore. It is Samsung's Own Operating System for Mobile Phones with good hardware like 1ghz processor and 512 mb ram. Its more than enough and power full hardware. The Samsung Bada OS maintains flash control, web control, motion-sensing fine-tuned shaking control, and face recognition.
[/step][step="" title="Who is owner or provider :"]
Samsung is the developer and owner of BADA platform. This is Samsung’s own operating system for smart phones anywhere Samsung Wave S8500 is the first mobile phone that determine ever utilize this OS.
[/step][step="" title="History :"]
Samsung s8500 is the first BADA mobile with BADA 1.0 then it updated to 1.0.2 and s8530 with BADA 1.2 and now BADA 2.0 is released .
The Bada resolve is to present a characteristic-rich display place for a new mobile computing familiarity. Touch Wiz UI.
[/step][step="" title="What I like:"]
- speed and user friendly view .
- no hang problem or that kind of any .
- app are good and graphics are great .
[/step][step="" title="What I do not like:"]
- No SMS or mms from other app for old version 1.0
- Security …