devopsy.kinsta.cloud

Tag: deployment

  • Deployment Units

    Deployment Units

  • 3 Ways Atlassian Usage is Evolving in the New Normal

    3 Ways Atlassian Usage is Evolving in the New Normal

    Over the last half-year, the use of Atlassian’s tools is evolving and expanding

    COVID-19 has rapidly accelerated the digital transformation of businesses by several years. However, as companies shift to digital-only workflows, DevOps teams and the increasing number of departments they interact with face numerous challenges. Effective digital communication and collaboration are often vital to overcoming these challenges, and executives now pay a lot more attention to the tools enabling both.

    Millions of users globally rely on the Atlassian ecosystem every day. In particular, Atlassian tools such as Jira being used to improve software development, project management, team collaboration and code quality. As the world has shifted to more collaborative digital work over the last half-year, the use of Atlassian’s tools is evolving and expanding.

    We recently conducted research to understand more about how users globally are using their Atlassian tools. The “2020 State of the Atlassian Ecosystem Report” surveyed 700 professionals using these tools for their organization to find out how, where, when and with what other technology they are deploying Atlassian solutions. Many interesting findings emerged from the research, and here are three major takeaways.

    Atlassian Tool Usage Seeps Into the Enterprise

    A large proportion of Atlassian users are adopting its tools to achieve business goals from improving productivity and efficiency to change management as part of their digital transformation. This is driving the introduction of Atlassian tools beyond DevOps and into the hands of non-technical teams.

    For example, 80% of users said at least one business team in their organization uses Atlassian tools. These teams include customer support, design, sales and marketing and operations. Furthering this trend, Atlassian and Slack announced last month that they would be conducting joint app and integration development, allowing users to connect platform services. Our research found 46% of Atlassian users utilize both Atlassian and Slack solutions. These kinds of announcements will only increase the collaborative use of these tools between DevOps and the teams they collaborate with.

    Adopting Agile Development Methodologies & DevOps Strategies

    A key part of a company’s digital transformation is adopting agile methodologies and clear DevOps strategies. According to our research, 77% of Atlassian users believe their organization has implemented agile principles in some way. And 48% have a DevOps strategy in place, with an additional 29% planning to implement a clear DevOps strategy in the next three years. As workers are forced remote and developers are distributed virtually, iterative development between these teams is increasingly important. This can only happen when a clear DevOps strategy has been put in place and digital feedback can be gathered and implemented in a well-defined way.

    Taking a Hybrid Approach to Deployment

    There are several different deployment options available depending on the business needs of users of Atlassian tools. How companies choose to use, deploy and configure the tools that they use. In addition, parts of the same organization often have different business drivers for using Atlassian tools. For example, one function may need a public-facing help desk with access from anywhere in the world, while another may need a highly secure and internal-only solution.

    There isn’t a one-size-fits-all approach to address personalized organization needs. For instance, 9% of users are leveraging a hybrid model of Atlassian Cloud (SaaS) and a self-hosted solution (Server/data center), which means combining the advantages of cloud and self-hosting through multiple deployment models.

    These findings demonstrate how the Atlassian ecosystem is evolving and expanding in our new normal. As digital transformation takes hold across different organizations of every size, industry and level of technical sophistication, the need for flexibility is only going to increase to accommodate more digital-only workflows.

  • A Philosopher’s Approach to CI/CD

    A Philosopher’s Approach to CI/CD

  • Survey: Organizations Knowingly Deploy Vulnerabilities

    Survey: Organizations Knowingly Deploy Vulnerabilities

    A survey published today by Synopsys, a provider of electronic design automation (EDA) and application security tools, finds nearly half (48%) of respondents admit they consciously push code with known vulnerabilities into production because of time constraints.

    Based on a survey of 378 cybersecurity professionals conducted by Enterprise Strategy Group (ESG) on behalf of Synopsys, the survey also finds 65% of respondents said developers in their organization are participating in a formal security training program.

    However, only a third (34%) are employing application security tools across more than three-quarters of their codebase. And, as the rate at which code is created increases, only 30% expect they will be able to protect more than three-quarters of their codebase 12 months from now despite the fact that more than half (56%) said they apply highly integrated sets of security controls throughout their DevOps process.

    Nearly three-quarters (72%) also said their organization makes use of 10 or more application security tools.

    Patrick Carey, director of product marketing for the Software Integrity Group at Synopsys, said the survey shows many organizations are making trade-offs between potential risks to the business and the desire to deliver software faster. As the rate at which updates to applications are being delivered increases, thanks largely to the adoption of best DevOps processes, Carey noted it becomes easier to justify knowingly allowing vulnerable code to be deployed in a production environment. The assumption is that most severe vulnerabilities will be prioritized while less critical vulnerabilities are addressed over the course of the application lifecycle management process.

    In most organizations, the survey finds either a development manager or the application security analyst is responsible for making these decisions. Just under a third of organizations make both jointly responsible. More than three-quarters (78%) also report their security analysts are directly engaged with their developers. Just under a third (31%) work directly with developers to review individual features and code, compared to 28% who work with developers on threat modeling and 19% that participate in daily scrums.

    The survey finds that integrations that complement high-velocity application development process are critical for 43% of respondents. As a result, more organizations are looking for application security tools that can be directly embedded within an integrated development environment (IDE), noted Carey.

    However, the fact that application security tools are shifting further left does not mean organization won’t also have to invest in other tools that are embedded within DevOps platforms that manage runtime deployments, added Carey.

    As is always the case when it comes to best DevSecOps practices, the two biggest challenges are getting the right tools in the hands of developers and then aligning workflows between development and cybersecurity teams. The survey suggests substantial progress has been made on the latter, while tools for developers are increasingly becoming available. After all, most developers want to do the right thing when it comes to application security. The issue is determining what precisely that means.

  • Data Types

    Data Types

  • ‘DevOoops’ Moves: Deploying Code Out of Step

    ‘DevOoops’ Moves: Deploying Code Out of Step

    ‘Everything as code’ can create opportunities for misadventure for DevOps teams

    DevOps’ ultimate aim is to create efficiencies in the software delivery process. But it doesn’t always work out that way. Sometimes DevOps initiatives lead to mistakes—something we lovingly call “DevOoops.” CloudBees recently polled some colleagues and came up with five examples of a DevOoops in action. Following is a discussion submitted by Director of Engineering Laura Frank Tacho about deploying code out of step.

    Scenario:

    Running in parallel during CI/CD can speed up your automated testing and shorten your feedback cycles. Just make sure deployment is not executing as a parallel step. That misconfiguration will cause your code to deploy at the same time the tests are running, regardless of their exit codes, pretty much defeating the purpose of automated testing before a deploy.

    This scenario touches on a theme we’ve seen throughout most of the “DevOoops” stories our colleagues have come up with. The theme is how the emerging concept of “everything as code” can create opportunities for DevOps teams to slip on proverbial banana peels.

    In this case, we’re talking about sequencing problems in a process we can call pipeline as code.

    To be successful, teams need to extend a quality-first approach in automated testing throughout their continuous delivery life cycle—from code to commit to test, as well as through the various tiers of the development life cycle. And with a quality-first approach, you need to apply testing and quality management to your environment configurations and infrastructure as code.

    Laura’s example highlights how teams need to treat their CD pipelines as applications themselves. They need to check for and eliminate bugs and errors in CD pipeline code to ensure that code is operating as expected. Failure to properly manage the creation and evolution of complex CD delivery pipelines will result in significant cost or risk.

    So, if you don’t have proper test coverage on application code, you could end up releasing an application that hasn’t been tested at all. If the app doesn’t pass through a security gate, as it’s supposed to, you could release unintended preproduction data.

    While there are always risks with untested code, we have to give unique consideration to untested or unmanaged CD pipelines. We need to consider the risks of what missed gates could mean for our developers, our organization and our customers.

    Teams should do the following as they release their CD pipelines:

    • Build: Start from the left-hand side of process and work through the defining and coding of CD pipeline left to right in the direction your apps and development artifacts flow: from dev to test to deployment. While we may not be able to define an ideal automation solution completely on the first pass, going left to right encourages teams to focus on what the life cycle of an artifact looks like.
    • Manage: Define your CD pipeline using an everything-as-code or pipeline-as-code approach. For this to add value, you must manage development of your CD pipeline as you would your application code and apply software best practices. Check your CD pipeline code into a source code repository and leverage language-specific technologies that can check your syntax. (If you’re using Groovy-based code or Jenkins-based code, there are versions of Lint that can perform these functions.)
    • Create staging environments: You should establish staging environments or test pipelines to validate your CD process. These pipelines should go through all checks and gates against your real tools, using reference code that is representative of the applications your pipeline would be servicing but stops short of production into environments.

    This will give you an opportunity to iterate changes against your application code, do some initial scans and checks to collaborate to define your CD pipeline in code-managing SCM. Execute initial validation on scans as pipeline as code and then validate expected operations in a staging environment before you deploy it as the basis of the pipeline for your production of business-critical applications.

    Key Takeaways

    • This story highlights how crucial it is to ensure that your application code and environments pass through certain gates and checks before being deployed out to the customer.
    • You need to construct your CD pipelines so your parallel testing is managed as a gate to production, ensuring that properly tested and validated changes are not automatically deployed.
    • Deployment happens at the end of all the processes within a pipeline, and all required tests, validations, checks and approvals have been done before any change is deployed to the customer.

    To read our previous “DevOoops Moves” post, click here.

    — Brian Dawson

  • Standardization, De Facto Style

    Standardization, De Facto Style

    The first decade or so of DevOps had one truth to it: It was about change. Not just change in the way that IT worked, but change in the way DevOps worked—particularly in the tools space, where products and product preferences both are in flux. We’re still seeing a massive change, but increasingly the effect is more like the ripples created when a rock is thrown into a pond than a tsunami, dumping change upon change.

    You could look at this one of two ways (and no doubt those who have more reason to dig into details than I have already done so): Either the slow but steady standardization typified by tools such as Jenkins and Puppet have enabled participation of enterprises in the DevOps life cycle, or the demands of enterprises for some amount of stability in their massively complex systems have driven standardization.

    Either way, the result is the same. We are seeing a lot of change further out, but the core technologies for build/test/deploy are settling into a few products by a few vendors. That is good for adoption, even if you would argue that it is bad for innovation. It means that skill sets are, at least to a certain extent, portable across DevOps teams and organizations, which for a long while was not true. When I was knee-deep in deployment technology, knowing how to use product A did not mean you knew how to use product B. The more people using one or the other, the better for employee mobility and the pool of available resources, as both people and support tools like standardized scripts.

    I recently was going through the offerings of a service provider in a space that doesn’t traditionally have DevOps enablement. The company’s offering included DevOps, so I drilled down. Seeing the company supported Jenkins, Jira and Xebia Labs made me feel better about the program it was putting together. It meant the company was adapting mainstream tools to a specialty market.

    That’s what spurred this blog. It’s been a long time that these things were seen as “new and shiny”; now, for a service provider to include them as proof it is serious about customers’ problems shows just how far we have come.

    There’s still a long way to go. The DevSecOps community is currently in the throes of growth, and lots of outer-edge DevOps tools are incompatible with each other and chosen per shop without a clear market leader. But we’re getting there. And at this point, a person going into DevOps who asks me what they should know will actually get an answer of “Learn X, Y, Z” rather than “You should learn X, but pick up some of X.1, X.2, and A too, then there’s Y …”

    The thing is, though de facto standardization is happening, to many (particularly enterprise) shops, this is all still new. So if you don’t know the recognizable tools yet, don’t worry too much; there will be opportunity to learn as they are rolled out across a given org.

    — Don Macvittie

  • Creatures of Habit, Snowflakes and Integration Tax

    Creatures of Habit, Snowflakes and Integration Tax

    Donovan Brown of Microsoft, in conversation with Matt Hilbert of Redgate Software, discusses database DevOps’ biggest challenges

    When DevOps was first talked about in Flickr’s seminal “10 deploys per day” Velocity presentation in 2009, it was regarded by some as strange and alien to corporate culture. It was the antithesis to the accepted way of doing things, a threat to established and proven processes—it was downright dangerous.

    Times have changed. Unicorns such as Uber, Airbnb, Spotify and GitHub couldn’t live without it. Microsoft has embraced it and actively promotes it. It’s become the key to gaining competitive advantage in a technology marketplace that is moving faster and changing quicker than it ever has before.

    But what about the database? Why are practices such as version control, continuous integration and automated deployment being introduced to application development but left on the shelf when it comes to the database? The 2017 “State of Database DevOps survey,” for example, found that continuous integration was in place for 39 percent of applications, but fell to 20 percent for databases. What’s going on?

    In search of some answers, we spoke to Donovan Brown, Principal DevOps Manager at Microsoft and DevOps advocate. Also known as The Man in the Black Shirt, his unofficial tagline is #RubDevOpsOnIt. He lives DevOps. In fact, you can’t stop him talking about it and enthusing about its advantages.

    He describes DevOps as “the union of people, process, and products to enable continuous delivery of value to our end users.” The most important of those three, according to Donovan, is people. It’s also, conversely, the most difficult to fix.

    ‘People are Creatures of Habit.’

    “If you’ve been doing something the same way for 30 years,” he said, “why would you fix it? We all resist change, even if change is for the better, and DevOps requires a lot of change.”

    A large part of that needs to come from the Ops side of the equation because, while processes including version control and continuous integration have become second nature to developers, Ops teams traditionally don’t do them on a daily basis. In fact, Ops are often seen as the opponents of change.

    Donovan does, however, hold his hand up as being partly responsible for the division. “Historically,” he said, “they’ve had to become the gatekeeper because developers like me 20 years ago were wreaking havoc on production servers, running on there with admin credentials. Their job in my opinion has never been to deploy software for us. Their job is to protect and manage the infrastructure, to make sure it runs as efficiently as it can. That history, though, stays with us because there is so much regulation and red tape to get code from the fingers of developers to the hands of users.”

    He sees DevOps as the solution to the problem. “What I’m hoping is that DevOps will help automate what we’re forcing them to do, which was never their job, and rebuild the trust between Dev and Ops. We really need to help Ops people realize that we’re not trying to replace them, we’re trying to empower and enable them to allow us to continuously deliver value.”

    It’s not down to Ops teams on their own, however. C-level executives also have a part to play because they often favor a traditional approach to software development, with targets and long term strategies standing in the way of DevOps.

    “What I’ve noticed in a lot of companies that are struggling to adopt DevOps is that they’re not getting the backing from the executive level,” Donovan saids. “You have this waterfall mentality from the top that still wants GANT charts and milestones, and things that just do not line up with agile thinking at all. I’ve had the best success implementing DevOps in organizations where the C-level executive got it. When you have a grassroots team who get it, but no one else does, they usually get snuffed out by tradition.”

    The database is not separate from Donovan’s goal of people, process and products coming together. Prior to joining Microsoft, he was a Process Consultant and Scrum Master, helping a range of companies introduce DevOps to their development practices. He made sure the database was part of that.

    Then, as now, including the database was a challenge, but Donovan worked around it, using the technologies available to allow customers to treat the database just like every other element in their DevOps solution.

    He does, however, admit it was hard work. “It’s actually the most difficult part of the pipeline to automate because of the risk of failure,” he said. “You can easily roll back a front end; you can’t do the same for your database because any transactions that have occurred during the deployment could potentially be lost. So, it’s a crucial, integral part of your DevOps pipeline and I challenge any company that claims to be doing DevOps that only does it for the front-end but their back-end is still done manually. To me, they’re faking it.”

    ‘Infrastructure as code should not be a special snowflake. It’s just part of your solution.’

    The key is to remember that the code written to make changes to a database is just that: code. Traditionally, it has been managed outside of and separate to application code, with database changes often managed on-the-fly, at the last minute. Consequently, deployments have become worrying at best, with teams on hand for the expected firefight against downtime.

    Include it in version control, however—and continuous integration and automated deployments—and the database can be developed in parallel with applications. Problems are then picked up earlier, deployments become predictable and reliable, downtime and rollbacks are a thing of the past.

    What has made this even more appealing is the tooling now available—software that in Donovan’s days as a consultant was only just emerging. As he admitted: “The tooling had to mature to allow us to get over a lot of the hurdles that are unique to database deployments so that we can have everyone incorporated into the DevOps pipeline, not just the unicorns. Everyone should have the power available to them to be able to take their databases and incorporate them as part of their DevOps pipeline. Until you do, you still have that being the bottleneck.”

    There is a price to pay, however, if by introducing tools to bring DevOps to the database, companies get bogged down by what Donovan calls “the vendor explosion.”

    ‘Every vendor you add to your pipeline also adds integration tax.’

    Integration tax is the cost to companies, in terms of training and introducing unfamiliar ways of working, to use a new piece of software that resolves a piece of the DevOps puzzle. If that cost is too high by, for example, moving people out of the development environment they’re comfortable with, it betrays the ideals of DevOps. One onerous way of working is simply replaced by another.

    Donovan is keen to remove that tax by encouraging companies to work with as few vendors as possible—and preferably those vendors who have already paid the integration tax in advance. By, for example, introducing tools that work inside or alongside existing software, thereby reducing the time it takes to become familiar with them, and making the most of the current infrastructure rather than adding to it.

    Otherwise, Donovan concluded, “You’re paying tax for that integration. When we at Microsoft have partners who create extensions for our products, it’s the vendor and Microsoft who pay the tax in advance.”

    Finally, I asked Donovan what the biggest challenge was for companies who adopt DevOps for the database. His answer was the most telling.

    “If you’re doing DevOps differently for your database and the rest of your system, to me there’s something wrong there. When I think of DevOps, the database is part of that. I don’t need a separate conversation about it.”

    About the Author/Matt Hilbert

    Matt Hilbert is a technology writer at Redgate Software with 20 years’ experience working for lots of the world’s biggest tech companies – and many of the smallest. He has a particular fascination for emerging technologies and is on a continuing mission to decompile, untangle, and explain techspeak to a wider audience, and excite people about the endless possibilities technology offers.

     

  • How To Fully Automate CI/CD – Even Secrets

    How To Fully Automate CI/CD – Even Secrets

    Imagine a world where your continuous integration/continuous deployment environment is 100 percent automated, including the passing of credentials.

    Capital One, a leading U.S. bank, has achieved this, and Andrey Utis, director of Software Engineering at Capital One, outlined how the company achieved this in his talk, “Application Secret Management with KMS,” at the All Day DevOps conference.

    iStock-683716072-1.jpg

    Andrey started by stating what we all know: Security needs to be at the forefront. Additionally, a message we heard over and over at the All Day DevOps conference is to automate where you can automate. That combination can be daunting and seemingly impossible—how can we automate security when someone needs to enter credentials and we can’t store credentials where everyone can get to them? After all, credentials provide access to databases that often contain personally identifiable information and other protected information. A breach could devastate companies and people, whether intentional or accidental.

    Andrey’s team uses Amazon Web Services (AWS), so they give instances IAM roles that allow them access to other AWS resources. What is the key (pun intended)? On an AWS EC2 instance, there is a magic IP address to which you can make an HTTP call and it will return temporary AWS keys. Those keys then make the API calls to different database services.

    Here is the solution: AWS KMS is encryption as a service. KMS Context allows you to add “salt” to the encryption. You can only decrypt with the same “salt.” KMS Key Policies restricts which IAM role can decrypt with the key/salt. Master KMS keys can be used only to decrypt their own keys.

    Below is a code sample of a KMS policy:

    Picture9.png

    This allows multiple applications to be on one AWS account while limiting access of developers to the applications they are authorized for.

    Here is the actual protocol:

    1. Create a KMS master key (can be shared by multiple apps)
    2. Create an IAM role for your server
    3. Add KMS key policy that allows decrypt to your IAM role for a specific context
    4. Encrypt your secret with the key and context and store the value in GitHub
    5. At deployment or runtime, invoke KMS API to decrypt

    There is a broader issue with IAM roles because credentials are generated by calling the “magic” metadata IP address 169.254.169.254. Developers in production, even with “read only” access to the instance, could call the KMS API to decrypt the secret. Developers should not be able to generate production IAM credentials at all, so you block the magic IP address with this code:

    Picture10.png

    To automate it and make it reusable, the team created a Chef cookbook, which they call a “briefcase,” to abstract decryption of secrets. They also have the iptables cookbook to block the metadata IP address for all except a whitelist of user groups, such as root and any application-specific group that makes AWS API calls (see above code).

    Andrey mentioned that Vault may have a viable solution soon. It uses signed EC2 Identity Document to verify the caller. The current downsides are that it only supports authorization by AMI ID (but should support more soon) and secrets are not source-controlled/versioned. As Andrey noted, that is not ideal for “configuration secrets” such as database passwords.

    In a follow-up question, Andrey was asked, “What were the lessons that were most critical to learn?” He answered, “This is a new field. Most companies either don’t fully automate or don’t fully secure the entire pipeline. So, there is little information out there.”

    Well, there is some more information in Andrey’s complete talk, which you can watch online here. If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free of charge here.

    Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here. This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed).  It’s all free and online on Oct. 24.

    — Derek E. Weeks

  • Spurring the DevOps Adoption Journey

    Spurring the DevOps Adoption Journey

    Every few years, the IT canvas is splashed with a new initiative that sparks enthusiasm among businesses and technologists alike. DevOps is one such philosophy gaining significant momentum in today’s digital transformation landscape. At the same time, the concept remains misunderstood and adoption is slow.

    DevOps embodies Development plus Operations within software development. Traditionally, these two parts of an organization have operated siloed from one another with marked differences in both ethos and approach. The result: delays in launching products and releases to the market. The fundamental principles of DevOps are to reduce barriers between Development and Operations; increase Development autonomy; and to automate Development and Operations activities to reduce wait time (and waste from a customer’s perspective), thus enabling faster time to market—all while keeping the end customer at the center.

    Planning the Adoption Journey

    Here are four different aspects an organization should consider before starting the DevOps adoption journey:

    Conduct an as-is continuous delivery assessment on product development practices and processes within the organization

    This will best determine an organization’s current maturity level across several different parameters, including:

    • Culture and organization
    • Build management and continuous integration
    • Environments and deployments
    • Release management
    • Testing and verification
    • Data management
    • Design and architecture
    • Information and reporting

    This process also includes identifying current automation levels and opportunities to automate, inclusiveness of tools and environments supporting continuous delivery, and an assessment of existing product design to determine if it lends itself to frequent and fast deployments.

    Map the journey of a piece of code from a developer’s desk all the way to when the consumers use it

    Utilizing a development pipeline assessment to study the life cycle of a piece of code through its journey from a developer’s desk to production will best identify “waste” during the life cycle. This assessment should bring out critical information, including the number of environment hops, test pyramid maturity and level of continuous testing, level of provisioning and deployment autonomy and its automation.

    Establish a culture of inclusiveness, autonomy and a sense of a ‘common goal’ within the organization

    Product management, development and operations teams should have a common mission and goal for the product, sprint or release they are working on. The definition here should be the value delivered to the customer as opposed to the value of code, test results, or individual deployment steps. Including operations roles within a close-working scrum team benefits this cause by:

    • Bringing in common views on what a product, release or sprint is intended to deliver.
    • Creating an opportunity to bring forward and address operations needs during the development cycle.
    • Creating a better understanding of mutual expectations and empathy for delivering outcomes that meet customer expectations.

    Measure and track

    Finally, determine parameters the organization would like to establish to track progress towards a successful adoption. The key here is to have a few, simple metrics that truly reflect “value to the end customer.” Here are a few commonly considered metrics:

    • Production deployment frequency: The number of product releases within a specified time.
    • Average lead time for a production change: The typical amount of time it takes for a piece of code to traverse from a developer’s desk through production.
    • Average production recover time: The time taken to bring back production systems after an incident involving a release, release rollback or system outage.
    • Change failure rate in production: The number of releases that did not stick in the live environment and needed either a rollback or an immediate emergency fix.

    The goal and a true measure of successful adoption would be an improvement of all these parameters over time. Internally, they would require strong engineering rigor and cultural realignment to be able to improve these customer-facing metrics.

    Navigating DevOps adoption successfully is neither easy nor fast for a number of reasons. DevOps encompasses different parts of the organization, which historically may have operated in silos and with different ethos. DevOps also questions the status quo regarding engineering roles and practices, and focuses on automation and reskilling, all of which need both upfront time and effort investment. Finally, DevOps believes in and propagates continuous learning and improvement, whereas many organizations may have more stepwise-based programs in place.

    For a midsized IT organization, it could take anywhere from 18 to 24 months or more to be able to reach a reasonable steady state. That’s why it is important to carefully craft a charter that encompasses the above parameters before embarking on this DevOps adoption journey.

    About the Author / Amit Gupta

    Amit Gupta is leader of Ness Digital Engineering’s DevOps practice. He has several years of software delivery background. He has keen interest and has developed deep expertise in establishing practical software development processes especially for globally distributed teams. Amit currently leads Ness Digital Engineering’s DevOps practice, and engages with several customers on such areas as improving engineering effectiveness, engineering tools and process transformation. Connect with him on LinkedIn.