devopsy.kinsta.cloud

Tag: devops teams

The Secret to Winning at DevOps: Are You Up for the Challenge?
The main idea behind DevOps is to enable companies to keep up with the increased software velocity and advancements in agile culture for a smoother end-to-end software delivery cycle.

The main goal of DevOps is to accomplish integration and automation, which is why implementing this philosophy can be challenging. Not only do you need to replace older methods and practices, but you’ll also have to change the mindset of the developers and the operations team to ensure they work in sync.

Several IT operations teams and software teams have adopted DevOps practices into their work culture for faster evolvement and improved innovations. The pipeline comprises continuous integration, testing, deployment, as well as monitoring application and system performance.

Introducing new DevOps tools and changing the mindset to prepare teams for the fast-paced world remains crucial for a successful implementation.

Despite the revolution that this philosophy brings to software development, several enterprises find themselves taking DevOps to an unproductive extreme. To remain productive, one of the aspects that teams need to work on is reducing rework, and the best way to ensure this is automation.

Understand How DevOps Works

Under a DevOps model, the development and operations teams are integrated into one to prevent them from getting siloed. This also improves collaboration and productivity.

You see, it brings alive the possibility of both the teams thinking more alike, working together and sharing responsibilities. This is done by automating code testing and workflows, automating infrastructure and continuously measuring application performance.

In some models, even the QA and security teams merge with the dev and ops. In cases where security becomes the primary focus, the name gets modified to DevSecOps.

In essence, the focus of DevOps is on automating processes that were otherwise manual and slow. Teams use a technology stack and tooling that can operate and evolve applications more reliably and swiftly. As engineers will be able to accomplish tasks such as deploying code and provisioning infrastructure faster with reduced issues, teams can reach testing and maintenance stages quicker.

Balance Between Standardization and Adaptability

Software products are mostly developed from the customers’ perspective, and if not, from end-user experience. Often, developers work backward to identify customer needs and wants for ascertaining successful innovation.

One of the biggest challenges when developing a software development life cycle (SDLC) strategy for organizations is to consider dynamic customer needs, strict compliance policies, unpredictable market trends and company goals. To ensure a consistent workflow, DevOps teams need to adopt standardization. In fact, workflows, technologies, processes, protocols and metrics need to be standardized before they can be automated.

This is also the main reason why organizations adopting DevOps need to strike a balance between standardization and adaptability. One industry that has excelled at this has been the financial industry, which has been leading the charge when it comes to adopting the latest software delivery practices and technologies, including DevOps. Financial executives view DevOps as being a way to improve security and risk and governance strategies.

The result is that cloud-based financial services are now automating virtually all of their processes through their software delivering pipelines, which makes tasks such as scanning receipts, sending invoices, tracking expenses or making payments seamless as they sync to your account. This simpler process is beneficial for boosting developer productivity and resource utilization, and for enabling enterprise scale management. If anything automating processes is becoming necessary for achieving higher product quality, compliance and scalability.

As mentioned above, new DevOps tools need to be introduced to team members to keep up with the constantly evolving strategies and implementation. But to prevent the creation of silos between teams, mechanisms need to be developed to make the adoption of new technologies easier.

Achieving the delicate balance between standardization and automation will help eliminate communication gaps, performance bottlenecks and silos between the different teams.

Benefits of Automation in the DevOps Landscape

The following are the advantages of adopting a DevOps philosophy:
- Code Development. Source control will keep everyone in the loop by managing, tracking and documenting any changes in code. This can be time-saving, and reduce the complexity of software projects.
- Smoother Testing. Testing is a continuous process in DevOps frameworks that includes system communication, several test integrations, predicting and tracking issues, and integrating approved automated builds. In the absence of automation, executing and managing continuous testing could be a rather tedious job that might cause problems between developers and the operations team.
- Better Visibility. The main job of the ops teams is to be aware of the code changes, ongoing problems and the impact of a specific code on the end goals. Plus, when they operate in a DevOps environment, they need to keep the developers in the loop as well.
  For example, if a system administrator from the ops team identifies code issues weeks after submission, it puts more pressure on developers. Now, the developers have two jobs: solve the problem in the previous code, and simultaneously work on making progress with the new code. This is what gets time-consuming, which can harm the company’s market standing. To remain ahead in the competition, innovation needs to be frequent and accurate.
  When there is a constant feedback loop between the dev, ops and QA, bottlenecks, and silos are eliminated, productivity is improved and customers are happier due to quicker innovation.
- Continuous Integration and Delivery. Automation can help deliver appropriate software built, data, code changes and tests to target environments. An example is how web hosts for e-commerce businesses need to be updated frequently for robust deployments. Automated testing will help ensure that code is delivered properly and doesn’t introduce new bugs, thus creating a platform with a superior user experience.
  This, in turn, helps DevOps teams to introduce frequent software changes by deploying error-free codes and continuous testing.
- Data Processing and Monitoring. The teams also need to measure and monitor the performance of their environment, which can be done by reading and analyzing system logs. But the existence of hundreds or thousands of servers in the environment can make it complicated.
  Automation will allow the teams to make sense of all the data and let them know how an application is performing and whether there are any bottlenecks.
Getting the Balance Right

Organizations need to realize that automation involves placing technologies around once-manual processes. The catch here is as the processes will become inherently repeatable, they need to be correct. Otherwise, organizations will only have flawed processes running faster, which will ultimately defeat the purpose of adopting DevOps in the first place.

Companies need to understand adaptability as well. This can be done by mixing both the old as well as new systems. For this purpose, an inventory of all applications, data stores and development processes for promoting meta development processes that include design, development, testing, deployment, configuration management and so on can be made.

In the end, the secret to winning DevOps is aligning DevOps tools with your organization’s goals – not following the footsteps of other organizations.
June 23, 2020
Untapping the Potential of DevOps, Part 4: Tips for Launching a DevOps Team

DevOps has become a hot strategy for IT teams across just about every industry—and for good reason. DevOps is built around increasing the velocity of the development pipeline, and in businesses where time to market is a key to success, it’s easy to imagine why DevOps has gained traction. While the tools and processes put in place are certainly essential, building the right team—from top to bottom—is maybe the most important factor for getting the most out of a DevOps strategy.

To help get the most out of DevOps initiatives—and to set teams up for long-term, sustained success—here are some basic tips for creating the team that will take development pipelines to new heights.

Change Is Coming

When kicking off a DevOps strategy, it’s clear that changes will be made. But, the extent of those changes may be underestimated. To get the most out of DevOps, it’s not just about changing up the tool stack or switching up meeting styles. The mindset around DevOps is at least as important as the processes. To squeeze the most juice out of a DevOps initiative, make sure the company and leadership understand what all DevOps entails and create the understanding that it requires a lot of internal changes to the existing culture. Getting leadership on board with the cultural changes that come with DevOps will go a long way toward driving success.

Talent Talks

This may go without saying, but it is imperative to build a team with the right skills for the task at hand. It can be easy to try to shoehorn people into roles, especially when trying to move quickly. But make sure to set individual talent up for success—both employees and the company will benefit. This means having DevOps engineers and leadership with the skills—whether they are technical, interpersonal or something else—to perform the work required.

Get Your Budget Right

DevOps helps create efficiencies. Leveraging automation, maximizing value delivery and getting products to market faster are all key tenets of a good DevOps strategy. But that doesn’t mean you should skimp on the important items. Like any project worth doing, it’s a lot easier (and more successful) when it is budgeted properly.

Make sure to have an adequate budget to create a team, perform the work and support the appropriate environments and infrastructure to perform the DevOps tasks and initiatives that need to be done. Doing this in advance will save a lot of headaches down the line and help develop a clear understanding of what is really needed to get from point A to point B—and help keep spending in line while the DevOps train is moving.

It’s Not Just About IT

Remember there are two parts to DevOps—dev and ops. It is often easier to get the developer side to buy into the strategy—after all, many of the tenets of DevOps speak to the technical teams. But overall buy-in is necessary for cooperation and involvement of all teams needed to achieve goals. That means development and operations—plus other departments within the organization, such as sales, marketing, the executive team, etc. Getting everyone on board with the process and rowing in the same direction will fundamentally change the mindset around how to design and deliver products. When the whole team is moving in lockstep, that’s when success can really be visualized.

By keeping the thoughts above in mind when planning a DevOps journey, organizations can help ensure teams are organized and set up for long-term success. But remember, every organization is different and has different requirements. What may work for one organization may not for the next.

When considering the potential of DevOps for your organization, it can be tempting to dive right in and skip some important considerations for setting up the initiative. But the key points listed above are tried-and-true and carry weight, no matter the size or scope of business. Having a leader who acts as a champion for DevOps efforts is essential, so IT professionals tasked with leading the organization into the DevOps transformation should arm themselves with these tips to be better positioned for success.

— Jonathan Fries

December 23, 2019
Common Pitfalls of Software Development and Tips to Avoid Them

In business, no one wants to plan on failure. However, when it comes to software development, failure is more common than most managers want to admit. In particular, many managers and executives fear large software-based projects are especially likely to fail due to the complex nature of these projects and the nuanced reality of the deliverables.

While there is no doubt a software development plan is complex, there is no reason to be so readily consigned to failure. In fact, it might be argued that software is so important to your operations that failure should be viewed as unacceptable. However, this aggressive approach in theory needs to be backed up with proper execution in practice. That is why you need to know the common pitfalls that befall most software projects. This is the only way to make sure your company avoids them.

Vague Project Requirements

One reason so many projects fall short of the mark is that these projects fail to define the mark adequately. Your software development project cannot succeed until you know what you really want it to do. This means your project specifications need to be clear from the very start. Your goals should be defined first, and then these goals should be consistently reiterated to team members throughout the process. This includes the scalability of the project. The development team needs to know what features should be included in order to produce a final software solution that actually meets your company’s needs.

This is all part of developing a versatile software development plan. A good software development plan will anchor your project from start to finish. A poor one will inevitably leave you vulnerable to failure.

Unrealistic Timeline

The timeline matters to the company, which is why some companies set aggressive timelines as part of their software development plan. However, while these timelines sound good in planning sessions, they may not make much sense in the daily development process. It is pivotal to think carefully about a timeline in order to account for development, testing and more. All parties should be consulted in the development of the timeline. This includes high level executives, project management and developers. This varied input should allow the project to accommodate the needs of management alongside the needs of developers. This is a form of risk management because an insufficient timeline will lead developers to cut corners, leading to a lackluster result.

Unbalanced Staffing Commitments

As you define your software requirements, you will need to think about the team members who will bring your plan to fruition. If you do not assign enough people to the project, production will fall behind. However, if you put too many people on the project, things can start to get messy. Overstaffing a project can easily lead to miscommunication, and it is harder to keep a large team of people unified. This can also lead to redundancy and a lack of consistency if too many duties are spread out. For these reasons, it is important to assess your staffing situation correctly from the start. Be sure to include your project management team in the final staffing decision.

Insufficient Testing Procedures

In all your planning, it can be easy to neglect testing. The reality is testing should be a critical part of your plan, accounting for a significant amount of your timeline and resources. Testing is important because it allows the development team to iron out any problems with the software. All software will have bugs in its early versions, and these bugs can be caught and fixed with sufficient testing. Testing is the only way to make sure your software works the way it needs to work. If you implement deliverables that do not perform, then your workers will be flummoxed, your consumers will be disappointed and your security could be at risk. Therefore, allot plenty of time for testing throughout the entire development plan, allowing for each component to be tested prior to going live.

Poor Hands-On Leadership

If you really want to make sure your project goes well, then make sure you have good people in place to lead it. Your project management team is absolutely critical to successful software development. A good project manager will internalize all parts of your plan. This includes the budget, the timeline, the goals and the staff. Your project managers need to facilitate communication, manage schedules and oversee adjustments. This key leadership role is your software development plan in action. Make sure you hire the person with the right skills and the right experience. Then, make sure that person knows exactly what your goals are to achieve success.

These pitfalls are common for a reason. However, with a little foresight, it is possible to keep your project and your company from disaster.

— Shane Zilinskas

September 30, 2019
Implementing DevSecOps Goes Beyond Technology

While technology is crucial for implementing DevSecOps, it is the people, processes and culture that drive it forward. As recently as last year, a survey found 58% of technology leaders cited existing culture and lack of skills as hurdles to being able to embed security testing and evaluation within software development processes. That report found that only about one in four companies strongly agreed their organization’s culture and practices supported collaboration across development, operations and security.

A separate recent survey on DevSecOps skills, conducted in partnership with devopsy.kinsta.cloud, found 70% of respondents said the security education they received is not adequate for what their current positions require.

Plenty of similar statistics can be found, and they point to a recurring theme–education, training and support for developers and security teams are as critical as modern application security solutions in implementing DevSecOps.

Automation Can Help Overcome Challenges

Most developers want to create high quality, secure code. Often, the problem is developers have never had formal training in what secure coding is, in either traditional education or while on the job. The good news is more organizations are starting to provide that training for development teams. As development and release cycles speed up, developers need to find ways to incorporate security testing in less intrusive ways.

In addition, development teams are gaining some control over budgets directed toward application security tools. Legacy tools for testing code and assessing application security risk simply weren’t built for the speed DevOps testing requires. Whenever evaluating new security analysis tools for a development team, automation should be top of mind. Static analysis tests the application code for a broad range of security flaws, and it can be fully automated into both the IDE and continuous integration (CI) processes. In the IDE, it provides early security guidance and education to software engineers while they are coding by highlighting potential vulnerabilities and suggesting best practices.

Companies can also reduce friction by ensuring developers don’t have to go out of their way to run the security tool. Development teams should be able to view and triage the results and take advantage of plugins and/or APIs to integrate security tools seamlessly into toolchains they are already using. This means there will likely be no one-size-fits-all approach that can be dropped into any dev team; rather, take the time to understand how that team works currently, and work with them to introduce the security tools in the least disruptive way.

Shifting Mentalities

One of the biggest challenges is asking developers to do something they weren’t doing before. With DevSecOps, it may seem like dev teams are being asked to take on more work, but in reality, the organization is replacing unplanned work with planned work. Rather than address defects late in the release cycle, development teams are scanning for and addressing flaws early on. Such a cultural shift can be plodding, but developers and development managers should realize embedding security this way will be more efficient and more secure while also reducing their unplanned work.

Giving development teams more autonomy over security tasks can also be daunting for security practitioners, but in order to facilitate shorter development iterations, security has to relinquish some control and also reconsider how they think about risk tolerance within the context of the business. Historically, the relationship between developers and security practitioners has been adversarial, but DevOps and DevSecOps methodologies have made it more cooperative. Still, many security teams are uncomfortable with the thought of giving up control.

Adapting to Avoid Adding New Technical Debt

Even with the understanding that producing more secure code benefits both development and security, reducing technical debt is gradual and starts with integrating security directly into the development process. It may seem convenient to lump security findings in with technical debt with the intention of getting to it someday, but it’s not practical to let security debt pile up.

Organizations are decentralizing security work, particularly via security champions: One or two people on each development team who serve as the eyes and ears of product security, taking ownership of some of the day-to-day tasks that would have previously been bottlenecked on the security team. A security champion could help with security code reviews or coach others on their team on how to fix security issues. Sharing responsibility for security in this way can further bridge the gap between security and development teams, reducing the workload of the security team while allowing development teams to be more self-sufficient.

For developers, context switching has a productivity cost. If they find out about a security defect while they are actively working on that particular feature or section of code, it’s only minimally disruptive and can be fixed quickly. By contrast, if they discover the same security defect two weeks later, after they’ve moved on to a completely different feature, they’ll incur the cost of context switching back to the earlier feature before they can fix the flaw correctly. Over the long run, finding and fixing flaws early in the SDLC should not meaningfully delay time to market.

Here are some best practices in implementing DevSecOps in your organization.

1. Embed Security Processes Early in the Development Cycle

Ensure scans are baked in at every stage of the software development process and work with your development teams to integrate security within existing workflows and tools. By the time software is pushed to production, code should have been scanned multiple times and all vulnerabilities should be fixed. Research has shown the frequency of security scans during the development process correlates to fix velocity. Specifically, businesses that do daily scans fix vulnerabilities 11.5 times faster than the typical organization.

2. Give Security Responsibility Directly to Development Teams

Developers need to take ownership of the security of their applications. This is the only way to integrate security seamlessly into their existing workflows. The perception of someone coming in and forcing tweaks to their code can be discouraging, but that isn’t to say security teams should be hands off. They need to take an advisory role, working with developers to ensure secure code. Training is key here. It’s likely developers will not be acquainted with the latest security strategies. Security experts need to educate developers on known vulnerabilities, threats and tools.

3. Identify a Security Champion on Every Development Team

It’s equally important to find someone on the development team who can go beyond automated testing tools to serve as the eyes and ears of the security team. Rather than assign the role to a member who already has additional responsibilities, choose someone who shows an interest in security. Because engineers may switch teams often, it’s best to have at least two security champions on each dev team. If one moves on, the institutional knowledge remains on the team and a new security champion can be trained up.

4. Automate Security Scans

Security cannot be an inhibitor to development. If it is, developers will fail to implement the proper security policies. With automated tools in place, development teams can efficiently test code throughout the software development lifecycle (SDLC), ensuring more secure applications while delivering software on time.

5. Take a Data-Driven Approach to Tracking Progress

Showing progress is crucial, both for developers who want to see the impact security is having on their software and for the management team who needs clear insight into application security’s return on investment. Analytics with compelling visualizations supports this value by providing quick and intuitive data so organizations can assess their current state and take action to improve their risk posture. Sophisticated analytics allows organizations to target critical applications and fix critical findings by defining a custom security policy based on their specific risk tolerance.

— Chris Eng

September 25, 2019
Online Experimentation: With Great Power Comes Great Responsibility

Recently we had the honor of giving a talk at this year’s Turing Festival. The festival, which is held in Edinburgh, is one of Europe’s biggest cross-functional tech conferences and is named after the late Alan Turing, who invented the Turing Machine. This invention cracked the Nazi Germany Enigma code, helped to end World War II and is the conceptual foundation of the modern-day computer.

So much of the technological advancements we benefit from today are a result of Alan Turing’s amazing achievement. But with the great power that Alan left us comes great responsibility. The responsibility we decided to speak on at the festival is ensuring you are not being misled by data.

Engineering teams are delivering faster than ever before. In the 1990s, a new feature would be released every few years, whereas today, apps such as Netflix see a new feature released hundreds of times a day. However, we need to make sure the value of the software we are delivering is not suffering at the cost of this increase in speed.

A great way to build this confidence and put out Turing-worthy features is by utilizing online controlled experimentation. Product managers can now utilize controlled experimentation across the full stack of their codebase. Experimentation can change the way in which we deliver new features. Instead of focusing so much on the speed at which new features are being released, it allows us to fine-tune the feature to meet the needs and demands of users.

All this speed of delivery doesn’t mean companies are getting it right 100% of the time–apps still crash and websites still fail. For example, we’ve seen companies such as Salesforce, US Bank and even Instagram suffer downtime following new feature releases. Online experimentation allows for DevOps teams to better understand the impact the upcoming feature release will have on their users.

Online experimentation requires you to split your traffic and randomize this traffic in an unbiased way, serving a new feature to a proportion of this traffic while the rest of your traffic does not experience the new feature. You can then compare the metrics of both these user groups to make an informed decision on whether to kill the feature or ramp it up to 100% of your users. You can run an experiment to a specific user segment, such as a demographic or market by utilizing feature flags within your code.

Online controlled experimentation also allows for real signals to be differentiated from noise. By noise we mean the randomness that is always apparent in the data due to using a sample to represent the whole population. The statistics from online controlled experimentation allow us to determine if the differences in the metrics are unlikely to be due to noise alone, in which case we can be confident our feature really did have an impact. This is how using online controlled experimentation decreases the chance of mistaking noise for a real, meaningful signal. In other words, it allows us to control and limit the chances of a false positive–a result that falsely indicates the change you introduced impacted your metrics.

We could spend ages discussing the benefits of using online controlled experimentation for feature releases (and we did at Turing Fest). However, the bottom line is experimentation allows you to be an outcome organization rather than an output organization. Taking the time to conduct an online controlled experiment means you will truly understand a new feature’s impact on your users and therefore you can be more confident in making your product decisions.

This article was co-authored by Sophie Harpur, product manager at Split. Sophie is passionate about making the complex world of experimentation accessible to everyone with core engineering, growth, design and product principles in mind. After graduating from the University of Strathclyde, Sophie worked for Skyscanner before eventually joining Split.

— Lizzie Eardley

September 23, 2019
Should Your Company Use DBaaS?

From SaaS to IaaS, companies are rapidly moving to the cloud to gain huge agility and cost benefits. So, is it time for your company to take advantage of database as a service (DBaaS)? Here’s a high-level discussion to help you along your decision path.

First, it’s important to distinguish DBaaS from simply running a database on a cloud-based server, such as Amazon AWS or Microsoft Azure. While you can certainly gain some cost and agility benefits from running your database on a virtual machine, you’ll still need to provision and maintain the database, that is, you will need server operations expertise.

With DBaaS, the cloud provider also provisions and maintains the database, eliminating the need for your organization to maintain server operations expertise in-house. DBaaS manages the entire environment—physical and virtual hardware, operating system, networking, replication configuration, etc.—so you can stay focused on software development. With the click of a button you can set up the database and then connect your application with a simple API call. And you’re ready to go.

The speed and cost advantages of this approach can be huge, but there are also some limitations, so it’s important to assess whether your company’s resources and your project’s requirements align with the current capabilities of the various DBaaS offerings.

Reasons to Use DBaaS

Lack of Expertise: As suggested above, if your technical team is mainly composed of software developers who won’t be able to manage the complexity of provisioning a database, you should consider DBaaS. In addition to handling the management of the database, the DBaaS provider will offer additional services, such as automatic backups of your data. In this worry-free environment, you can focus on optimizing your software instead of constantly worrying if the database is functioning properly.

Short-Lived Databases: If you need databases to serve as back ends for continuous integration testing, DBaaS will allow you to rapidly provision the databases, populate them with test data and then delete them when they are no longer needed. Having the database provisioned for you makes it far faster and simpler to build the required automation for the testing environment.

A Microservices Design: DBaaS can be particularly helpful, even in a production environment, if you are using a microservices design composed of a very large number of databases. Even if you have the internal expertise, you may not want to invest the time and effort in deploying all those databases. DBaaS can get you into production significantly faster.

Reasons Not to Use DBaaS

While the above benefits are appealing, you likely won’t want to use DBaaS in the following scenarios.

Database-Centric Applications with Complex Topologies: To ensure ease of deployment, DBaaS providers limit the ability to deploy complex environment topologies. This reduces the flexibility DBaaS customers have. For example, let’s say that for disaster recovery, you have a primary synchronous replication cluster in one region and a secondary synchronous replication cluster in a different region, with an asynchronous relationship between them. This relatively complex topology is outside the scope of most DBaaS offerings.

IO-Bound Workloads: If your database has IO-bound workloads, you may need very powerful hardware, including high-end CPUs, terabytes of memory and very fast storage. In this case, you may not find a DBaaS provider that offers a configuration that will meet your needs.

Understand Your Options

If your database requirements align with the capabilities of DBaaS, you now have the ability to eliminate significant operational complexity and develop, test and deliver your applications faster and at a lower total cost. However, make sure you spend time carefully investigating today’s DBaaS offerings, including Amazon RDS, Google Cloud SQL and Azure SQL Database, which all have different features and focus, including deployment models, performance trade-offs, instance types and more.

If your needs don’t fit current DBaaS offerings, you’ll need to provision your databases yourself. If you don’t have the expertise in-house and can’t afford new hires, a database consultant may be a cost-effective strategy for getting the support you need.

— Tyler Duzan

September 20, 2019
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

September 19, 2019
Why DevOps is Like Football
When it’s done right, DevOps is an impressive feat. You have groups of professionals all melding together as one large team working toward a common goal. The groups–and the individuals themselves–perform their roles and hand off tasks to each other at just the right times. They follow pre-designed plans, but they constantly tweak those plans, in real time, to deal with variables that threaten to undermine the whole mission.

This is DevOps in action. But take a closer look at some of the descriptors above and ask yourself if it sounds like something else that’s starting to creep into a lot of conversations this time of year. If you’re a sports fan like me, this sounds just like football.

Let’s face it, football parallels have been attached to all kinds of institutions and practices–everything from the military to business to marriage. The emphasis on discipline, teamwork and execution can apply to most initiatives in everyday life.

But I’d argue that football’s very structure aligns especially well with what we do in DevOps.

In football, the goal is to move the ball from the line of scrimmage to the end zone. In DevOps, we have our own starting and ending points. Think of our line of scrimmage as the point where features get added to the application and our end zone as the point where an application is successfully delivered to a customer. Football has its individual units (offense, defense, special teams) and we have ours (development, quality assurance and operations).

In football, the offense players have different specialized skills and all work together to move the ball forward to reach the end zone. The players start with a set of instructions (plays), which they all understand. This is like automation in a DevOps environment. A DevOps team execute its own plays, collaborating and improvising as needed to achieve their shared goal.

Picture what this would look like in a pro football game:
- The quarterback passes the ball: Think of a software developer handing off the application to a test engineer.
- Linemen block for the quarterback: This is like quality assurance continuously protecting the application from bugs that threaten to sack the whole project.
- A receiver runs a route and catches the ball: This is similar to an operations engineer preparing a server and receiving the application.
- A running back runs the ball into the end zone for a touchdown: The application is deployed. Goal!
The team has worked together and achieved the goal–in this case, a touchdown. They will be able to repeat this success time and time again because they have repeatable plays and they collaborate.

Without a DevOps approach imagine what a football game would look like:

No Automation: The team has no plays. Nobody on the field has any idea what his assignment is on each snap, so players basically do their own thing. All the speedy, skilled players yell “Throw it to me!” This kind of freelancing might work for youngsters playing pick-up football, but it won’t work in a more advanced game.

No Collaboration: The positions don’t work together. Even if team members have plays and know them, if the linemen don’t block as a unit, a play will fail. If a running back zigs when linemen are opening up a hole for him to zag, the defense will stop him.

No Shared Objectives: If everybody knows the play but they’re only concerned about executing their parts of it, the offense won’t get far. Imagine:
- The quarterback being concerned with just getting the ball in the air, not where it goes or even if it is caught. The receiver can worry about that. End result: Lots of failed passes–and probably a few interceptions.
- Linemen will block, but they’re not worried about who to block or when. End result: Lots of quarterback sacks.
- Receivers will run routes, but they’ll choose where they want to go. They might run beautifully, and even get open periodically. But if the quarterback doesn’t know where the receivers are, the team won’t complete many passes.
Without a DevOps approach, the chances of getting a ball to the end zone would be very low. And when it did get there, the process would be messy and unrepeatable.

When football is done right, teams defend well, score a lot of points and rack up victories. When DevOps is done right, organizations deliver high-quality software to customers in a rapid, repeatable and reliable way. DevOps, like football, codifies a winning process that serves a vast group of stakeholders both inside and outside of the organizations playing the game.

— Brian Dawson
September 17, 2019
Radical Transparency in DevOps and ITSM Helps Achieve Excellent Customer Experience
Here’s what I’ve noticed after spending several years in service management: DevOps is coming up more in the conversations I’m having with service desk leaders. Usually, these conversations start with one of the similar questions: DevOps is going to be the death of ITSM, correct? Alternatively, some consider DevOps as a challenge, and ITSM doesn’t seem so relevant because you don’t have in-house development going on.

I always answer these questions in the same way: ITSM is relevant, and DevOps is not a threat to it. There’s more to it, however. ITSM professionals can still achieve their most relevant goal–excellent customer service.

If you allow me a moment, I’d like to offer some background as to why excellent customer service is essential for every ITSM professional, then walk through some of the ideologies or frameworks used and how they interact. I’ll close this piece by discussing what radical transparency means in practice and how it can help you achieve an excellent customer experience.

Some Background

When discussing DevOps, we usually see three parts: Development, operations and the actual business. The business demands different things from both development and operations. Development teams are asked to push out code as fast as they can, and operations teams must keep the existing services available and make sure everything is stable. Development is trying to fulfill as many business needs as fast as they can, while the operations team is accountable if things go wrong.

These might be extremes, but these are the traditional silos that have their expertise, priorities and goals, but there is no holistic overview. These internal organizations also use their way of working, based on a framework or ideology: DevOps tends to use agile, the business uses lean and ops focuses on ITIL. These ideologies can clash and compete at times.

Because so much is happening with DevOps, we see significant developments. The speed of development and deployment is increasing, leading to additional continuous delivery advancements and technology implementations. The collaboration and breaking through walls between the development team and the operations team for deployment has come a long way within many organizations.

Meanwhile, ITSM professionals face more and more challenges. Apart from the existing incident handling, they encounter incidents about newer, faster releases. Also, how are they supposed to deal with knowledge management, an already complicated process in itself? The increased speed of development makes it look as if they are always running behind. Getting out of that reactive approach is not getting easier.

Customer experience and satisfaction is the number one priority in ITSM, creating quite the challenge. In ITSM, all input comes in: If things do not work at all or break down; if things do not work as expected; and if users need help to get things working. Good feedback also usually comes in via the service desk. When examining customer experience, there is a thin line in how fast you can go: If functionality is delivered too quickly, customers will not be able to use it. When delivered too slowly, customers will be unhappy about it as well.

You can argue that a new silo comes into the picture–namely support. The support team keeps things up and running. Likewise, there are communication links between the customers and the other silos where they can filter bugs to development, info on any outages to operations and feedback on how the customer perceives the value of the functionalities to business.

What if you don’t have in-house development? Well then, DevOps and the link with ITSM can be even more challenging, meaning you only have part of your DevOps and some of your support outsourced. For one application, perhaps you are relying on one or multiple vendors, but it might be the case that your vendor is dependent on another vendor.

In other words, the process looks more like a plate of spaghetti than a smoothly laid smooth IT process. There are significant benefits to outsourcing, which is why we keep using outside vendors for some of our operations. In these cases, consider the shift of responsibility, the extra expertise, stability and continuity you gain. However, there are also downsides, such as loss of transparency.

A Shift in Responsibility

Shifting responsibility does not mean the same as a shift of accountability. Your ITSM team will still have to take ownership because even if you are not controlling everything. You have to be in control. In the end, you are still responsible for your customer experience and happiness. Customers do not want to wait two years for new features because the update of the vendor cannot take place for whatever reason. Also, it would be best if you had insight into what is going to happen for your users, and you need extra insight regarding how everything is working.

Silos make this a challenge without outsourcing and are even more so the case when outsourcing these responsibilities. Before we move forward with solutions, let’s first take a step back and look at the frameworks and ideologies the different silos are using. As discussed, first, we have ITIL, typically used in operations.

“ITIL is the most widely accepted approach to IT service management in the world. ITIL can help individuals and organizations use IT to realize business change, transformation, and growth,” stated Axelos on their website. It’s about aligning services to the needs of the business and supporting its processes.

Next, we have lean, which is about maximizing customer value and minimizing waste. Lean is where value stream mapping comes in. You identify what works then look at how you can improve flow. Finally, agile, the cultural aspect of DevOps.

At first sight, each of these processes seems contradictory, but actually, this is not the case. The key is using each of these principles correctly. For example, consider CAB, which comes out of ITIL. In many cases, the A in the acronym stands for “authorization” instead of “advisory.” Knowing that might make things much better and can open up the possibilities of automation, which is crucial to improving things.

Likewise, some people tend to say that agile can never work in an ITSM context because it is against processes, but that’s also not true. Agile speaks to individuals and interactions over processes and tools, not without appropriate processes and tools. However, if you take a step back, you see they have more in common than you might think and some changes coming to ITIL4, for example, already address how to achieve a better correlation between the three.

Let’s look at all of them together. Usually depicted as a horizontal value stream, but looking at it as a continuous loop, makes things a lot clearer for me.

When you start in the business with the idea, take it through the design, code, build and test phase, then move over to the release and deploy and then we get into ITSM territory with the support and monitor stages. Where you see the blue line is where DevOps focuses mostly, so this is also where you witness the creation of a new silo: support (where ideologies or frameworks come in the picture).

Radical Transparency

So how do we break through these silos? Radical transparency. First of all, silos have to share their common purpose, which in the end is excellent customer experience. You can change it however you want; but in essence, that is what the business, development, operations and support all strive.

To accomplish this, we first must know what impacts the customer experience.

Let’s break it down: There are visible and invisible effects for the customer that can either be positive or negative. Visible results on the positive side will be features; on the negative side, defects. On the invisible side, positive things include architecture and process improvements. On the negative side, technical debt.

For excellent customer experiences, we need to focus on the visible effects. Invisible effects must be worked on, too; if completely neglected, these will become visible at some point. The most prominent and the first focus should be on the visible effect. To do that, we need insight. If we all have the same set of information, often we all come to the same result. Getting to that same set of information requires radical transparency and also sharing information and insights.

Shared Workload Tooling

First disclaimer: When I talk about sharing tooling that does not necessarily mean using one tool. I will specify. I mentioned before that ITSM professionals have to know what is going to happen that might affect the customer experience. They have to be aware of which new versions are coming out and which customers are going to be or are on that version. For that reason, you need to share relevant information from your release orchestration tool to your ITSM tool. For instance, in our service management tool, we can see who is on which version via an automatic integration.

That is a flow from DevOps through ITSM. The return flow also is essential. Any feedback that comes through your ITSM process regarding bugs has to flow back as well. So, for that, you need an integration between your ITSM and bug tracking tools. I also have seen some examples within the ITSM process where a Kanban board is used to improve collaboration between development, operations and support.

Just making visible those tasks that impact customer experience and being able to follow up on the progress made by all stakeholders is so valuable. It also gives the support team the necessary insight to be able to communicate with the customer.

If you are working with one or multiple vendors and dependencies there, you will want to include vendors in this as well. Moreover, that might mean you even have to tie in your and their ITSM tools.

Another thing you want to share is customer satisfaction insights. First, measure satisfaction throughout the entire chain. That includes employee satisfaction, as well. We have seen the proof that employee satisfaction has a direct impact on customer satisfaction, so make sure you have all those data available and insightful.

Knowledge Sharing

Next up is sharing knowledge, which requires proper documentation. Think of federating knowledge into a knowledge base to make relevant information available to the right people. Make sure you have a good understanding of each other’s processes, and the impact they have on one another is essential. As an example, we had some challenges in collaboration with one of our hosting partners. When we sat down to discuss this with them, we found out some choices we had made in the deployment and support process, were not as reliable because we had assumed things about how the hardware had been set up and those assumptions were not correct.

Excellent documentation and communication are key. If you have things outsourced, you want to make sure your vendor is the right partner, and you have a common understanding.

Another important thing that should be shared is dashboards, where you can have a total overview of all parties involved and the impact they might have. You especially want to have visible what the effect is on the customer experience. It is valuable to have insight into all things that need your attention, but for your shared dashboard, focus on those things that are not going well and that have an impact on the customer experience.

When you work with one or more suppliers, you want to make sure they are also using these dashboards and actively monitoring these. For you to be sure they use that, add that in your vendor selection criteria. The only way this works is if there is that radical transparency, where all parties involved have access to your vendors, development, operations, support, business and customers.

Takeaways

Hopefully, because of this article, you’ve taken some additional perspective about where DevOps and ITSM come together, why the silos have to be broken down and how working with one or multiple vendors can be especially challenging. Also, hopefully, I’ve provided a bit of background on the various best practices, frameworks and ideologies most used and how they share commonalities. Radical transparency means breaking through the silos and how this can improve your customer experience.

Finally, to sum it up:
1. Make sure all parties have a common purpose and are doing everything to achieve that.
2. Share relevant information. All words here are significant: share to achieve radical transparency, applicable because you don’t want to flood people with things that are not of use to them, and sharing too much may distract them too much. Provide just the relevant information so everyone can focus on the common purpose.
3. If you do all that, you will produce better value for your customers, all for excellent customer experience.
— Jeroen Boks
August 26, 2019
5 Tips to Eliminate Knowledge Gaps in Dev and QA
To create and release high-quality software, the software development lifecycle (SDLC) was established using different roles and processes designed to work seamlessly together. This approach is of critical importance because it spans the initial planning phase, all the way through production release and monitoring.

Roles vary within projects but typically include designers, business analysts (BA), developers, testers, scrum masters, project managers, product owners (PO) and technical architects (TA). Each one brings different expertise and skills to a project but ultimately, they are meant to collaborate and determine how to implement different aspects of the software.

The amount of processes can also vary for projects based on team size, release schedules, availability of resources and the complexity of the software.

What is the Knowledge Gap?

Without a distinction of responsibilities or a roadmap that identifies who owns each task in the SDLC, everyone assumes someone else will complete the tasks. The result is that the majority of these important steps remain incomplete or undone.

The reason this happens is because a knowledge gap exists among the team. This is especially true when teams are a mix of entry-, mid- and expert-level individuals. Sometimes, assumptions are made regarding the skill set, experience and domain knowledge that each individual brings to the project. Knowledge gaps can also develop at a more granular level, with teams using the same tools but in different ways. As an example, developers and testers might be using a single testing platform quite differently.

As teams begin collaboration on features for the software, they may encounter the following situations:
- Each team member has a different interpretation of the project requirements
- Developers assume testers have their same level of technical expertise
- A lack of ownership and assigned responsibilities among the team
- A PO has a feature idea and each team member has different ideas for how that feature should work
- The TA explains how a feature should be implemented using technical jargon that designers, POs, BAs and testers don’t understand
- A tester is not allowed appropriate time to complete testing due to tight release schedules
Identifying Knowledge Gaps

Knowledge gaps not only negatively impact the release of high quality software, but also team morale, productivity, job satisfaction and empowerment. The first step to finding acceptable solutions is to identify exactly where a knowledge gap exists. Some questions to help teams do this include:
- What are the common problems that occur in each phase of the SDLC?
- What processes are in place during the requirements, design, development, testing, acceptance and release phases of the SDLC?
- How effective is the communication between different roles in the team?
- Are the responsibilities of each team member clearly identified?
- How visible is the status of the project at any given time?
- How often are release cycles pushed to accommodate for more development and testing?
- Are the teams aware of what kind of customers are going to use the product?
- Is the velocity of the team stable? How often does it fluctuate and by how much?
Bridging Knowledge Gaps

Finding gaps in a team’s knowledge is the first step. The next step is determining how to narrow the divide. The following key factors help bridge the knowledge gap in teams:

Training

Sufficient training and tools should be provided to help teams do their jobs better. Proper training has a domino effect on the success of the project. It helps designers understand how to design mockups so developers can effectively implement the feature; testers can attend code reviews without intimidation and use tools more effectively; developers will understand why the testability of a feature is important and understand which tools can aid the development testing effort; the scrum master can better manage project tasks; the project managers can ensure the team collaborates to meet release schedules and deadlines; and finally, stakeholders can have an overview of the project through reports that are generated using various tools.

Visibility

For teams to work seamlessly together, we need to ensure the results of everyone’s efforts are visible to the entire team. It is important to understand how each contribution maps to the overall goals of the project. To increase visibility, teams can consider using the following:
1. Checklists: a list of items to be completed during each phase of the SDLC. If the items in the list are marked as done, then there is no ambiguity about which tasks need attention.
2. Visual Dashboards: give a high-level overview of the project’s health and status. These can be created on whiteboards, easel boards or in software and during daily meetings, teams can address the dashboard to ensure everyone, including business stakeholders, are aware of the high-level project status.
Clear Definition of Roles and Responsibilities

Each person needs to understand his/her role on the team, as well as the tasks they must accomplish on a daily, weekly, monthly or quarterly basis. Goals, objectives and expectations for each team member should be defined and discussed with respective peers and/or managers. This eliminates confusion and increases productivity and task completion.

Empowerment

In an age where individuals are increasingly more technical and skilled, what they still lack in their job functions is empowerment and autonomy. Contrary to the conventional wisdom that a project needs a single leader, the leadership responsibility can be effectively divided within each role on the team. Having one point of contact each from the design, development and testing teams means each can help to lead their respective sub-teams and help to ensure everyone within the project is working toward the same goals and objectives. By operating within this structure, the whole team becomes empowered.

Experimentation

Once sprints are completed and knowledge gaps have been identified, the whole team should come together to discuss solutions to existing problems. Based on this discussion, the team can start experimenting with different solutions to determine what works well or doesn’t. This constant experimentation and feedback loop helps to make the team more creative and empowers them to come up with solutions that work for their organization.

In summary, the knowledge gap has been a major obstacle for development teams in reaching their fullest potential. By identifying and reducing these gaps, teams can be more efficient and achieve faster release cycles with higher quality software.

— Raj Subramanian
August 23, 2019