devopsy.kinsta.cloud

Tag: devops

  • REP SPOTLIGHT: getITright

    REP SPOTLIGHT: getITright

    DevOps Institute: Tell us a little about your organization.

    getITright: With offices in Australia, South Africa, The Netherlands, Nigeria and Malta and a network of partners operating in 31 countries, we offer a bouquet of services to help organizations to:

    • Manage better
    • Lower risk
    • Perform better
    • Make better business and IT decisions

    Our service offering includes:

    • Training courses – Learning best-practice through our Partner Academy courses or network of training providers
    • Accredited IT Best practice course material – License our training material
    • Consulting – We use an agile approach for projects and a lean approach for operations when consulting and coaching.

    DevOps Institute: What other topics do you teach or consult on?

    getITright:

    • Service Management: ITIL®, ISO/IEC20000, Lean IT, Service Desk Institute
    • Governance of Enterprise IT: COBIT® 5
    • Project Management: PRINCE2®, PRINCE2® Agile, DSDM AgilePM®, Scrum
    • Information & Cyber Security Management: ISO/IEC27001, NIST Cybersecurity using COBIT5
    • Quality Management & Business Improvement: ISO9001, LEAN SIX-SIGMA
    • Risk & Continuity Management: ISO31000, ISO/IEC27005, ISO22301
    • Cloud Computing

    DevOps Institute: What type of interest in DevOps are you seeing in your region?

    getITright: DevOps awareness in the region is still low, but we see a steady increase in the level of interest in the topic.

    DevOps Institute: How do you think that DevOps contributes to the business’ value stream?

    getITright: It makes projects and business as usual faster, more stable, with less risk.

    DevOps Institute: What topic area in DevOps excites you the most?

    getITright: DevOps enables organizations to improve productivity and respond to change with less risk. It’s easy to adopt by organizations with mature ITSM practices in place.

    DevOps Institute: Why should enterprises and individuals consider formal DevOps training?

    getITright: Training ensures that all resources in the organization are in sync when implementing new practices like DevOps in an organization and ensures a cohesive approach that facilitates proper organizational buy-in and adoption.

  • Scrum Co-Creators Unveil New Version of the Scrum Guide

    Community Input Contributed to Addition of Scrum Values to Official Scrum Body of Knowledge

    Boston – July 6, 2016 – Scrum.org, the mission-based organization dedicated to improving the profession of software delivery through training, certification assessments and community, and Scrum Inc., the world’s premier Scrum training and consulting provider, today announced Scrum co-creatorsKen Schwaber and Jeff Sutherland’s updates to The Scrum Guide, a framework for developing and sustaining complex products.

    In a webcast earlier today, the pair came together to unveil the new version to the industry.  The Scrum Guide now includes a section on Scrum Values, which are Courage, Focus, Commitment, Respect and Openness.

    “When the values of Commitment, Courage, Focus, Openness and Respect are embodied and lived by the Scrum Team, the Scrum pillars of Transparency, Inspection and Adaptation come to life,” explained Schwaber. “We added these values to The Scrum Guide because successful use of Scrum depends on people becoming more proficient in living these five values.”

    This is the first update to The Scrum Guide since July 2013. While refinements are made at their discretion, Schwaber and Sutherland encourage community feedback via The Scrum Guide User Voice website, where people can post ideas for changes and vote on them. The addition of Scrum Values to The Scrum Guide was the most popular request on the User Voice site.

    “Ken and I regularly read and support the User Voice forum, taking into consideration each suggestion from the community,” said Sutherland. “This update to The Scrum Guide officially recognizes the significance these values have to any Scrum team.”

    The recording of the webcast will be made available soon by both organizations. The Scrum Guide can be found at http://www.scrumguides.org/. Offered for license under the Attribution Share-Alike license of Creative Commons, its copyright allows for reuse as long as it is credited back.

    About Scrum.org

    Based on the principles of Scrum and the Agile Manifesto, Scrum.org provides comprehensive training, assessments and certifications to improve the profession of software delivery. Throughout the world, our solutions and community of Professional Scrum Trainers empower people and organizations to achieve agility through Scrum.  Ken Schwaber, the co-creator of Scrum, founded Scrum.org in 2009 as a global organization, dedicating himself to improving the profession of software delivery by reducing the gaps so the work and work products are dependable.

    Visit Scrum.org for further information on the organization’s Professional Scrum assessments, training and global community; follow us on Twitter @scrumdotorg and read more from our community of experts on the Scrum.org blog.

    About Scrum Inc.
    Scrum Inc. is the world’s leading authority on Scrum. They provide training, consulting, and counsel to individuals and companies across industries including energy, finance, defense and technology. They are thought leaders in the community publishing books, scientific papers, case studies, blogs, and creating online educational content. Founded by Jeff Sutherland, the co-creator of Scrum, Scrum Inc. has helped hundreds of companies fundamentally re-shape themselves to face a changing world, dramatically increase productivity, and drive profound growth. Jeff’s most recent book is Scrum: The Art of Doing Twice the Work in Half the Time, which has sold over 100,000 copies worldwide.

    Visit ScrumInc.com to learn about our services and explore our online learning resource ScrumLab. Follow us on Twitter @ScrumInc or contact us throughinfo@scruminc.com, we would love to hear from you!

  • Cohesive Networks Customers Validate VNS3 4.0 Elevates AWS Security

     Newly Released 5-Star Rated Application-Layer Network and Security Software Now Available
    AWS SUMMIT – LONDON, UK – 6 July, 2016 – Cohesive Networks, a cloud-native security and networking company, today announced the availability of VNS3 version 4.0 in the AWS Marketplace, and all cloud environments. Cohesive Networks’ innovative approach to application-focused security differentiates VNS3 as the first software-only virtual network appliance that offers end-to-end encrypted networking capabilities at the application layer. VNS3 4.0 includes a new, hardened underlying Operating System (OS), delivering deeper insight into network security, and elevating the level of application protection beyond what was previously available.
    “We went from 90% on-premises to 99% in the cloud in about 30 – 45 days,” said Chris Cata, Manager Network Operations at Foley Carrier Services. “Our cloud migration project almost didn’t happen without Cohesive Networks. VNS3 helped us achieve the flexible, multi-site VPN connectivity we needed, while Amazon’s built in VPN products did not.”
    Over 2,000 VNS3 users have shaped the direction of the product, from an encrypted IPsec VPN device to a more robust product family that offers network management, cross-cloud connectivity, and high availability. VNS3 customers have been successfully running cloud networks for over 800 million hours without any major, reported outages.
    “Years of experience in enterprise networking and security have taught us to look further into the future, beyond predictions or fears,” said Patrick Kerpan, CEO of Cohesive Networks. “5-star sentiment in the AWS Marketplace validates that VNS3 offers the end-to-end control cloud users need to flexibly connect and secure their applications.”
    VNS3 4.0 Update Includes:
    With VNS3 4.0 customers can build secure overlay networks on top of AWS cloud networks to enable network capabilities such as transitive routing, multicast protocols, as well as networking functions including reverse proxy network intrusion detection (NIDS) and load balancing.
    VNS3 version 4.0 includes security focused updates for VNS3:net, VNS3:ms, and VNS3:ha software products. The VNS3 virtual appliance is built on Ubuntu Linux and incorporates Docker container systems.
    Availability:
    VNS3 is available in over 20 public, private, and hybrid clouds. Cloud and virtual environments that feature VNS3 products include: Amazon EC2 and VPC, Microsoft Azure, CenturyLink Cloud, VMware vCloud, IBM Softlayer, Google Compute Platform, ElasticHosts, and Rackspace.
    VNS3 4.0 is available in beta on the cloud Marketplaces of Amazon AWS, and will soon be available on Microsoft Azure, and ElasticHosts. Contact Cohesive Networks to get started today: sales@cohesive.net
    Release notes: find out more about the technology behind VNS3 at Cohesive.net/support/release-notes
    About the VNS3 Product Family:
    VNS3 products help enterprises secure and connect their critical applications deployed to the cloud. VNS3 secures and connects applications above hypervisors, infrastructure, or data centers control. All Cohesive Networks products are software-only virtual appliances, available for most public, private, and hybrid clouds.
    VNS3 has recently won the 2016 Network Computing Awards Network Project of the Year – Private Sector Award, the 2015 Cloud Innovation World Cup for Industry 4.0, a finalist in the Cyber Security Awards for Best Security Company of 2015, listed in the CIO Review’s Top 20 Most Promising Enterprise Security Companies of 2015, won the 2014 EuroCloud Awards for Best Offering IaaS/PaaS, and won the 2014 Cloud World Series Best Security Solution Award.
    About Cohesive Networks:
    Cohesive Networks provides cloud-class security and networking software for enterprises. Over 2,100 customers use VNS3 virtual appliances to secure products and services at the application layer. With VNS3, enterprises can extend networks into public, private and hybrid clouds to provide security, connectivity, and integration.
    Cohesive is a member of the Amazon Partner Network, an Amazon Marketplace Seller, a member of the Microsoft Partner Network, Microsoft Azure certified, a Google Cloud Platform Authorized Technology Partner, a CenturyLink Cloud Marketplace Provider, certified HPE Helion Ready, and an IBM Business Partner. To find out more, visit www.cohesive.net
    ——————————————————-
    ###
    Media Contact:                      
    Heidi Groshelle
    Groshelle Communications
    @heidigro
    Cohesive Networks Sales Contact:                      
    Chris Purrington
    19 Eastbourne Terrace
    Paddington, London W2 1BA

  • Groundbreaking Technology for DevOps Omniscience; JFrog Announces Immediate Availability of JFrog Xray

    SANTA CLARA, CA–(Marketwired – Jul 5, 2016) – JFrog, the worldwide leader in infrastructure for software management and distribution, today announced the immediate availability of JFrog Xray, its pioneering product for accelerating software delivery by giving organizations unprecedented insight into their software packages and containers.

    As the industry’s first universal artifact analysis product, JFrog Xray works with all software package formats and a multitude of databases as it deeply and recursively scans every type of binary component ever used in a software project and points out changes or issues impacting the production environment.

    “The early response to JFrog Xray has been phenomenal,” said Shlomi Ben Haim, founder and CEO of JFrog. “We’re excited that more and more organizations will now be able to benefit from this pioneering technology for gaining radical transparency into the huge volume and variety of binary components used in development. The combination of validating with security databases, along with acquiring metadata from JFrog Artifactory makes JFrog Xray the only tool in the world that not only scans the container or software package, but also provides a full dependency graph and impact analysis to the user. Our goal is to address the real DevOps pain and not just to send another scanner to the market!”

    As organizations increasingly transform from isolated teams and role-specific tools to common delivery pipelines shared by global teams and driven by seamlessly interoperating tools, they need to understand all the binary artifacts they produce, across all product lines and geographies, and taking into account changes to global application deployment and distribution over time.

    JFrog Xray addresses this need by providing deep recursive scanning to repeatedly peel back the layers of software components and their accompanying metadata to uncover security vulnerabilities or other issues down to the most fundamental binary component no matter what binary packaging format the organization uses. This deep scanning of the dependency graph provides organizations the ability to perform impact analysis on changes to their package structure.

    JFrog Xray is a fully automated platform with a powerful REST API, enabling integration with an organization’s CI/CD pipeline as well as with all current and any future types of component-scanning technology.

    It integrates with a universal range of databases and security platforms so that critical necessities such as security vulnerability analysis, license compliance and component version analysis and assurance become possible not only at build time but across all of the enterprise’s binary digital assets.

    JFrog Xray is available now at https://www.jfrog.com/xray/free-trial with a special webinar on JFrog Xray on July 14 — http://bit.ly/23gL143. More information about JFrog Editions —https://www.jfrog.com/pricing

    Resources

    About JFrog
    More than 2,500 paying customers, 60,000 installations and millions of developers globally rely on JFrog’s world-class infrastructure for software management and distribution. Customers include some of the world’s top brands, such as Amazon, Google, LinkedIn, MasterCard, Netflix, Tesla, Barclays, Cisco, Oracle, Adobe and VMware. JFrog Artifactory, the Universal Artifact Repository, JFrog Bintray, the Universal Distribution Platform, JFrog Mission Control, for Universal Repository Management, and JFrog Xray, Universal Component Analyser, are used by millions of developers and DevOps engineers around the world and available as open-source, on-premise and SaaS cloud solutions. The company is privately held and operated from California, France and Israel. More information can be found at www.jfrog.com.

    CONTACT INFORMATION

    • Media Contact
      Kelly Ferguson
      Kulesa Faul for JFrog
      (862) 223-9346
      Email Contact
  • How to Fail at Test Automation

    How to Fail at Test Automation

    Let me start by admitting that I am not a test automation expert. I have done some work with test automation and have supervised teams who practiced it, but when it comes to the intricacies of it, I have to call a friend. It is from such friends that I have learned why so many test automation efforts fail. Talking to people about test automation validates my impression that this is the DevOps-related practice that people most often fail at.

    Let me share the four reasons why test automation fails, in the hope that it will help you avoid these mistakes in your test automation efforts.

    Before I go into the four reasons, allow me one more thought: Test automation is actually a bad choice of word. You are not automating testing, you automate quality assessments. What do I mean by that? It is a mistake to think of test automation as automating what you otherwise would do manually. You are finding ways to assess the quality of your product in automated ways and you will execute it way more often than you would do manual testing. This conceptual difference explains to a large degree the four reasons for test automation failure below.

    Reason 1: Underestimating the Impact on Infrastructure and the Ecosystem

    There is a physical limit of how much pressure a number of manual testers can put on your systems. Automation will put very different stress on your system. What you otherwise do once a week manually you might now do 100 times a day with automation. And into the mix an integrated environment, which means external systems need to respond that frequently, too. So you really have to consider two different aspects: Can your infrastructure in your environments support 100 times the volume it currently supports, and are your external systems set up to support this volume? Of course, you can always choose to reduce the stress on external systems by limiting the real-time interactions and stub out a certain percentage of transactions or use virtual services.

    Reason 2: Underestimate the Data Hunger

    Very often test automation is used in the same system where manual testing takes place. Test automation is data-hungry, as it needs data for each run of test execution and, remember, this is much more frequent than manual testing. This means you cannot easily refresh all test data whenever you want to run test automation and have to wait until manual testing reaches a logical refresh point. This obviously is not good enough; instead, you need to be able to run your test automation at any time. There are a few different strategies you can use (and you will likely use a combination):

    • Finish the test in the same state of data that you started with;
    • Create the data as part of the test execution;
    • Identify a partial set of data across all involved applications that you can safely replace each time; or
    • Leverage a large base of data sets to feed into your automation to last until the next logical refresh point.

    Reason 3: Not Thinking About the System

    Test automation often is an orchestration exercise as the overall business process in test flows across many different applications. If you require manual steps in multiple systems, then your automation will depend on orchestrating all those. By just building automation for one system you might get stuck if your test automation solution is not able to be orchestrated across different solutions. Also, some walled-garden test automation tools might not play well together, so think about your overall system of applications and the business processes first before heavily investing in one specific solution for one application.

    Reason 4: Not Integrating it into the Software Development Life Cycle

    Test automation is not a separate task; to be successful it needs to be part of your development efforts. From the people I have spoken to there is general agreement that a separate test automation team usually doesn’t work for several reasons:

    • They are “too far away” from the application teams to influence “ability to automate testing,” which you want to build into your architecture to be able to test the services below the user interface;
    • Tests often are not integrated in the continuous delivery pipeline, which means key performance constraints are not considered (tests should be really fast to run with each deployment);
    • Tests often are not executed often enough, which means they become more brittle and less reliable. Tests need to be treated at the same level as code and should be treated with the same severity. This is much easier when the team has to run them to claim success for any new feature and is much harder to do when it is a separate team who does the automation. It also will take much longer to understand where the problem lies.

    Of course, absence of failure does not mean success. But at least I was able to share the common mistakes I have seen and, as they say, “Learning from others’ mistakes is cheaper.” Perhaps these thoughts can help you avoid some mistakes in your test automation journey. I do have some positive guidance on test automation, too, but will leave this for another post.

    And in the case you found your own ways of failing, please share it in the comments to help others avoid those in the future. Failures are part of life and even more so part of DevOps life (trust me, I have some scars to show). We should learn to share those and not just the rosy “conference-ready” side of our stories.

    Test automation is for me the practice that requires more attention and more focus. Between some open-source solutions and very expensive proprietary solutions, I am not convinced we in the IT industry have mastered it.

    One bonus thought: If you cannot automate testing, automate the recording of your testing.

    If you cannot automate testing, find a way to record the screen with each test by default. Once you identify a defect you can use the recording to provide much richer context and make it a lot easier to find the problem and solve it. Verbal descriptions of error are very often lacking and don’t provide all the context of what was done. I keep being surprised how long triage takes because of the lack of context and detail in the defect description. There is really no excuse for not doing this. Record first, discard if successful, attach it to the defect record if you find a problem.

  • REP SPOTLIGHT: Omnikron

    REP SPOTLIGHT: Omnikron

    DevOps Institute: Tell us a little about your organization.

    Omnikron: With over 30 years of industry experience, we have honed IT and project management training techniques to ensure that course material caters to our clients’ needs. Our training is not just lectures from a book. We offer world-class courses, assessments and simulations in a variety of formats and at various paces. As the workplace has changed in the 21st century, so has the training approach here at Omnikron.

    DevOps Institute: What other topics do you teach or consult on?

    Omnikron: Omnikron’s most popular training includes ITIL, PMP, TOGAF9, Change Management, DevOps, Security & Security Awareness and Cloud.

    DevOps Institute: What type of interest in DevOps are you seeing in your region?

    Omnikron: There is a lot of talk about DevOps and our classes are slowly but surely increasing in size. Hopefully by the end of the year, we will have a packed house for our classes.

    DevOps Institute: How do you think that DevOps contributes to the business’ value stream?

    Omnikron: We have honed in on ITIL for years and DevOps is such an easy transition for most of our students. Not only are the students enjoying the class, but they are able to use their past experience to share stories in class as well as apply what they have learned outside the class.

    DevOps Institute: What topic area in DevOps excites you the most?

    Omnikron: Organization consideration and practices seems to be the favorite among our students. Plenty of dialogue has been given around this particular topic.

    DevOps Institute: Why should enterprises and individuals consider formal DevOps training?

    Omnikron: Because DevOps is designed to help our student continually improve their services to their internal and external customers. Can’t get any better than that!

  • TASC Powers Up DevOps Pipeline

    TASC Powers Up DevOps Pipeline

    Technology team members at TASC, a leading administrator of employee health benefits, were feeling the chains of manual processes that kept them from moving software out at more than a snail’s pace. Development, operations, quality assurance (QA), project managers (PMs) and business analysts who were pushing code to test, staging and production environments or performing user accepted testing (UAT) tests needed to forward features through the pipeline much more quickly.

    “We were doing one release a month, shutting down the entire website for six to eight hours on a Saturday morning to complete deployments,” says John Gildenzoph, DevOps engineer at TASC.

    The company took to orchestrating its pipeline using Automic Release Automation (ARA) to onboard DevOps and catapult software innovations into production.

    Manual Challenges

    Before ARA, TASC used Jenkins—that was pretty much its first step into DevOps-style automation. Before that, the company’s processes were, for the most part, all manual, implemented with a source code repository.

    “For anyone to deploy the application for development on their workstation, or to a test environment or even to production, they had to go out to the server, check out the source code, build the source code and deploy the artifact,” says Gildenzoph.

    TASC was doing that on up to 30 JBoss servers—which were its main web servers—using only two developers. One developer started on the first node and the other started on the last node as they worked toward the middle, updating each server individually and manually, he says. “We came from the Dark Ages where there were really no other products we were using other than the servers and our version control software. Jenkins was the first iteration where we figured out that we needed to be running builds all the time,” Gildenzoph notes.

    Uniting DevOps Tools, Filling Gaps

    TASC uses ARA to unite a variety of DevOps tools into the pipeline and to fill gaps where there isn’t a specific tool. “ARA is platform-agnostic. You can use it like an assembly line and you can plug the worker applications in along the assembly line as you like,” Gildenzoph says. In one example, TASC uses Jenkins as one of those “worker applications,” i.e., as its build tool: ARA tells Jenkins to build the software, then moves the software along itself to the next tool to do the next job.

    According to Gildenzoph, all a company needs to add best-in-class tools at each step in the development process along the pipeline is a command line interface (CLI) or API that enables them to script that tool in to integrate with ARA. That way, if the company decides to use a new tool for any part of the process, it can simply script that tool into the ARA at that point, rather than replace the entire pipeline with one new tool for everything.

    TASC also uses ARA to orchestrate in its use of Amazon EC2 and the ECS products. At the same time, TASC is working to add the management of Docker containers into ARA in the same way.

    TASC IaaS

    TASC uses ARA to create the entire dev, test, staging and production environments where the company will deploy the software. Using the ARA and its automation engine, which is a sort of complex chron that develops the workflows, TASC interacts with its Amazon cloud presence to create the entire application stack.

    “We see that Automic is working on its next evolution of the ARA product, which is a provisioning product that will interact with various cloud technologies such as Amazon or OpenStack so we will be able to create that environment in less of a homegrown manner. It will be more of a drag-and-drop capability with run books to interact with your cloud,” Gildenzoph says.

    These cloud technologies also will be like the applications/worker setups in Gildenzoph’s ARA assembly-line analogy.

    Revving Up Results

    “We moved from our original manual scenario to the point where in some cases we don’t need downtime to deploy the software. We have the orchestration in place and it manages to bleed off part of the cluster, update that cluster, and then bring those portions back online so that our customer doesn’t notice,” says Gildenzoph. This benefits internal and external customers who use the site for call center processes and submitting flex claims, respectively.

    TASC is more agile since the adoption of Automic, releasing software typically on a weekly timetable. This enables the business to respond to requests from customers for new features, innovations and enhancements to the site more quickly and efficiently.

    When TASC purchases another company to add its products to TASC’s, an accelerated pipeline enables the company to onboard that company and products more swiftly and seamlessly.

  • Does Security Slow Down DevOps?

    Does Security Slow Down DevOps?

    Since the primary goal of DevOps is to eliminate bottlenecks to increase a company’s speed and efficiency, organizations tend to embrace new strategies that make DevOps even more efficient. However, when it comes to integrating security into DevOps, there is some debate whether such integrations help to improve the success rate of the DevOps process.

    The Security Dilemma

    Some arguments against integrating security into DevOps include:

    • Security and DevOps function better separately,
    • There is no need for security in DevOps, or
    • Security will somehow slow down the creativity driven by DevOps.

    Some say security integrated with DevOps stifles the work flow and innovation due to its restrictions. In other words, security can viewed as getting in the way of development, or being overbearing to the process, because it is not geared toward rapid development, but rather toward safety.

    Another Perspective

    Despite the arguments against integrating security with DevOps, security breaches because of neglecting safety during development can be a nightmare. For example, software or a website attacked via an overlooked vulnerability point, or a major bug to the code, costs the company in terms of time, money and competitive edge.

    Not only can it crash the product, but it also can halt sales or seriously damage the reputation of the product or site. If security is not integrated with the fast-paced DevOps team, security problems often are not solved or even detected until well after the product is released. This can make it very difficult for the security team to limit the negative effects of any security problem.

    The Benefits of Integration

    Security integrated with DevOps creates an opportunity for the security team to fix and identify problems or vulnerabilities before the product is launched—and before the stakes are suddenly much higher and much more costly.

    Integrating security into DevOps allows the security team to protect the code and the products from within, while they are being created.

    It can be compared to safety inspectors being part of a team that builds a railroad: Wouldn’t it be easier for them to identify any problems with the railroad while it is being built, rather than trying to fix them after a train crashes?

    Security from the Beginning

    It is true that DevOps and agile development involve being very adaptable to change and making rapid prototypes and new products that account for errors, flaws or even security risks. However, just because a DevOps team can move fast doesn’t mean the business won’t be more profitable if it can prevent security risks in the first place.

    Developers don’t possess the same knowledge and skills security professionals have. For that reason security professionals should be included in the development process to increase the chance of releasing a stronger and more effective product.

    The database specifically is an area that can spell disaster. Security and regulatory compliance should be a central component of DevOps for database to prevent unauthorized and undocumented changes to the database and a potentially disastrous security breach.

    It’s important to protect a developer’s creativity and workflow, but most companies have room to integrate more security into their DevOps team. Doing so might just save them from huge problems down the line.

    Next Steps

    Here are a few key steps to enable secure DevOps:

    1. Configure the dev, test and deployment environments identically.
    2. Make proactive changes to all environments automatically, significantly reducing the opportunity for engineers to make security mistakes.
    3. Create a secure process and determine roles and responsibilities as early as possible in development stage.
    4. Perform all vital secure connectivity reviews during the development process.
    5. Implement separation of duties across your entire release process.
    6. Fully automate your deployments to reduce the need for manual access and attended processes.
    7. Ensure your database does not become a compliance and security risk.

    About the Author/Yaniv Yehuda

    yaniv-e1404303491389Yaniv Yehuda is the co-founder and CTO of DBmaestro, an enterprise software development company focusing on database development and deployment technologies. Yaniv is also the co-founder and the head of development for Extreme Technology, an IT service provider for the Israeli market. Yaniv was a captain in Mamram, the Israel Defense Forces computer centers, where he served as a software engineering manager.

  • SimplyHealth Uses DevOps to Manage Mobile Testing

    SimplyHealth Uses DevOps to Manage Mobile Testing

    SimplyHealth, a private company health insurance plan provider in the United Kingdom, saw its mobile web traffic trending upward with no end in sight. “While this was good news, there was concern whether the customer experience and the company’s ability to provide continuous application delivery on mobile devices might erode as a result,” said Chris Dale, information technology test and release manager at SimplyHealth,

    A good half-dozen challenges in mobile testing and development stood at the crossroads between mobile customer demand and SimplyHealth’s mobile development speed and ability to respond to needs for improvement.

    With some help from Mobile Labs, a provider of internal cloud mobile device testing for software, SimplyHealth allayed its fears of customer dissatisfaction.

    Mobile Web Test, Dev Challenges

    Dale noted SimplyHealth’s challenges to mobile web test and development were many. Among them:

    • Testing came late in development, causing the testing team to find issues at later in the development process and leading to costly rework for developers.
    • The vast array of mobile handsets that needed to be tested against, which affected productivity and increased expenses because of the time spent searching for, ordering and waiting for devices to be shipped to SimplyHealth for testing.
    • The development team’s use of mobile device simulators for testing mobile software on different device platforms—a process that did not represent accurately the behavior of actual devices.
    • The differing behaviors of Apple and Android devices in some functional areas, which made it impossible to do cross-platform testing with a single script.
    • Testing eventually  became a bottleneck, jeopardizing SimplyHealth’s award-winning customer service levels for its mobile customers.
    • The digital marketing team had difficulties in verifying customer experience on mobile devices.

    An all-encompassing solution for the SimplyHealth mobile web testing team would enable early testing and cross compatibility with the needs of all affected departments, including marketing.

    Dale said the tool would have to meet 34 requirements, including:

    • Allow for the highest levels of security and compliance with the Data Protection Act (similar to HIPAA regulations in the United States)
    • Provide the ability to use the existing automation framework and toolset and hook into SimplyHealth’s continuous integration solution for automatic test execution
    • Offer a way to swap devices in and out quickly and easily
    • Provide easy accessibility from any location
    • Have a simple user interface
    • Maintain high levels of performance
    • Offer scalability for future growth
    • Come with backing by dependable, knowledgeable support and a solid development road map

    The Solution

    After looking at four possible testing solutions based on products listed in Gartner’s Magic Quadrant, SimplyHealth decided on Mobile Labs deviceConnect to manage mobile devices for testing software. This on-premises cloud solution provides the accessibility and flexibility of the cloud and the security of on-premises technology, protected by the security measures available to the enterprise for its other assets, such as firewalls.

    The physical installation largely amounts to a mobile cart and rack for plugging in many different mobile devices for testing. “DeviceConnect enabled SimplyHealth to have a product-agnostic virtual lab so we could all easily test software on the devices using our own in-house testing scripts,” Dale said.

    Mobile Labs was willing to configure and demonstrate a proof of concept mobile device web application test setup using deviceConnect to show the SimplyHealth team how it worked to manage apps and devices for testing. “After we thoroughly evaluated this configuration, we concluded that Mobile Labs deviceConnect was the best choice,” Dale said.

    Implementation

    Mobile Labs implemented the entire solution for SimplyHealth, from setup to installation to ensuring it integrated well with SimplyHealth’s existing Hewlett Packard Enterprise testing tools, Dale noted. “We were immediately writing automation scripts to use with it. We had it working in production the next day.”

    All affected teams and departments have fully adopted and use the Mobile Labs tool, including testing, development, branding, user experience and support teams, he said.

  • Scania: Adopting DevOps for Auto Production

    Scania: Adopting DevOps for Auto Production

    When you think of large vehicles, chances are you think heavy-duty front and rear axles, suspensions and cab parts. When you think of large engines, chances are you think crankshafts, cylinder heads, pistons and injectors. When you think of the brains behind a company that produces all this, you should think software and the processes that create it.

    Swedish automotive company Scania was building its software intelligence using large, legacy development approaches, coding entire software packages as a single project. The organization’s teams were couched in silos. Releases were highly infrequent.

    Everything changed when Scania scaled and conquered the partitions and divisions that separated teams and adopted agile practices and DevOps.

    Scania and its Software

    Scania, a large global maker of heavy transport buses and trucks and marine and industrial engines, runs many software departments. Its Connected Services department creates web-based portals, APIs and embedded software that transmits live and historical data transmitted to and from drivers and vehicles for logistics including positioning, tracking, service planning, geofencing and messaging.

    Scania’s move toward DevOps accelerated in the 2012-2013 time frame, when the company combined developers and testers into feature teams and molded its first DevOps practices. The company had a host of development issues before that.

    “Before 2012, we were organized around traditional big software projects, which slowed progress and hindered communication. We had long lived branches and a product release cycle of about three releases a year. Silos existed between Dev, Ops, Test and Marketing,” said Anders Lundsgard, technical architect at Scania Connected Services. By 2013, he added, feature teams were adopting processed based on a strict adherence to Scrum.

    Scania’s Dev and Ops teams were housed in different locations and working separate goals that were not aligned or cohesive. These teams suffered from confused communications and increasing stress as development worked only on new features while operations tried to use the new software in a stable way in production.

    Pivotal Changes

    Everything started coming together when Scania formed feature teams that progressively shouldered more of the responsibility for forwarding code to all environments and making it work. “There was no involvement in this from operations or infrastructure as they supported tooling and automation for on-premise infrastructure and shifted software to a cloud platform,” Lundsgard said.

    Scania ultimately added Perforce Helix, a software configuration management tool. As long as software engineers know that the focal point of their work is checking in their code, the Perforce product can be the single point of storage of any one software component for all projects in the deployment pipelines. This way there are no multiple, correct current versions of any piece of code that could cause confusion. “Perforce has a number of capabilities that help engineers collocate software for reviews and even shelve files as they pass between developers,” says Lundsgard.

    Scania uses Perforce Helix in combination with its continuous integration (CI) environment and processes to improve quality beyond what manual testing could ever accomplish. “The goal is that software engineers check code into Perforce Helix at least daily,” Lundsgard said.

    Scania DevOps Processes Today

    Scania now versions every change and automates builds, tests and deployments, with CI as a central development practice. The company no longer uses feature branches, with everyone adding code directly to the mainline. “We use a microservice-oriented architecture in order that each feature team can manage and own certain services,” Lundsgard said.

    Different teams approach development with varying degrees of DevOps maturity. Some teams deploy software continuously, sometimes many times per day. Other teams benefit from using some manual testing and may not deploy software for a few weeks. “The tooling has enabled all teams to have a fully automated process for pushing their code into all environments if they choose—automatically or via a click of a button,” Lundsgard said.

    Remaining Challenges

    Scania next plans to fully automate every component of infrastructure from the network to the servers. “Some of our infrastructure and operations people have started to adopt infrastructure as code and they version that code in Perforce Helix as well,” Lundsgard said.