devopsy.kinsta.cloud

Category: Blogs

  • Adopting Continuous Testing: 4 Success Stories

    Adopting Continuous Testing: 4 Success Stories

    Much has been written about the benefits and best practices of continuous testing. However, it’s not always clear how to make these concepts a reality. Here are a few stellar examples of how several leading organizations were able to apply continuous testing to remove roadblocks and achieve their organization’s distinct quality goals.

    The Middle Child Rises – Testing Evolves to Quality Engineering

    Ann Lewis, ExxonMobil

    ExxonMobil’s philosophy is centered on safety, security and controls as the foundation of our 135-year-old company. Based upon our fundamental policy, quality has become a key component in delivering software. We are currently undergoing a shift from traditional project management organizations and support organizations to product teams. This shift has highlighted the need for testing early in the development cycle and to combine new development with ongoing maintenance.

    Testing, the team “in the middle,” has become an integral component of the ExxonMobil development life cycle as “Quality Engineering.”

    To do this, we started with the basics—quality control manages risk—and then explored what is tracked today and whether quality is being measured. We also removed the roadblock to continuous testing. In the end, the Quality Engineering team has created the expectation that testing is a part of everyone’s mindset; that continuous testing and deployment can only be accomplished through model-based testing; and that managing quality reduces overall cost of ownership.

    Continuous Testing: How Vantiv is Maturing

    Sandra Baker, Vantiv

    Previously, Vantiv shared our automation journey and how we got started. Now, will share how we are maturing as a QA organization and in the use of Tricentis Tosca.

    Our focus has shifted to how we manage and execute our 15,000+ tests. We have focused on unattended execution to achieve maximum benefits. The next step was to further advance in CI/CT/CD and our maturity. To do this, we have introduced new metrics and processes.

    Finally, we are expanding our capabilities to end-to-end testing, performance testing, user acceptance, service virtualization and big data testing.

    How A1 Telekom Austria Speeds its Delivery with Continuous Testing

    Remove featured image

    Christian Fischl, A1 Telekom Austria & Walter Pindhofer, Qualysoft

    The automated tests enable A1 Telekom Austria AG to deploy new features faster and with less risk. This leads to shortened release cycles and more agility. While it is still an ongoing transformation, it has already become a huge success story. This session is all about A1 Telekom Austria AG’s journey to continuous testing, starting with the first automation to the sometimes-tough steps toward automated system regression tests, and a look at the future plans.

    How Varian Achieved Quality @ Speed in Regulated Environments

    Manish Mathuria, Infostretch

    In the new world of digital, agile and DevOps, traditional approaches to software delivery no longer apply. Development and testing teams are under immense pressure to deliver quality products at speed. Varian Medical Systems, a leading manufacturer of medical devices and software for treating cancer, implemented sales and service management solutions using Salesforce, ServiceMax and SAP. To keep up with continuous quality demands in regulated environment, the company partnered with Tricentis and Infostretch to automate testing of key processes. This session highlights Infostretch‘s automation solution using Tricentis Tosca, nuances of testing SaaS models, and key test case, test data and environment management strategies.

    — Jessica Wanivenhaus

  • DevOps in the Cloud: Security’s Groundhog Day

    DevOps in the Cloud: Security’s Groundhog Day

    Throughout the internet age, enterprise IT has given security a lower priority than qualities such as speed-to-deployment, scalability, availability and usability. We first saw this in the late 1990s and early 2000s, when IT teams rushed applications onto the web. Amid the glee surrounding the potential of fancy new internet architectures, few thought about the possibility that these applications could become portals into the enterprise for criminals. So, the credo among development organizations was “move fast, deploy fast and seize the future.” There was no concept of risk management, beyond considerations such as availability, scalability and usability. This laid fertile soil for what would become the breach epidemic.

    As we progressed through the years, breaches became so common and massive as a result of the “web evolution” and there became a dire need to manage information security risk. Thus, enterprise security was born. As it evolved, these departments worked closely with IT management, development, infrastructure and business teams to create frameworks that aligned business goals, risk, security and agility. Security and risk management became important parts of development processes and business operations.

    Finally, there seemed to be a path forward to a more secure future … until the future changed.

    Related Content:

    How Developers Can Take a More Proactive Approach to Security

    How Blockchain Tech Can Make DevOps Better

    The future became the cloud revolution, and it plunged us back into the same festering pool of security negligence that we saw two decades ago. Indeed, when it comes to deploying applications in the cloud, security professionals likely can relate to Bill Murray’s character in “Groundhog Day.” Only in the real-life case, they repeatedly relive the same scenario regardless of what they do.

    As DevOps Teams Gain Power, Things Become Less Secure

    Since the emergence of cloud computing, enterprises once again have rushed to take advantage of a new deployment paradigm, and they are prioritizing factors such as scalability, availability and cost-containment, leaving security as an afterthought. As DevOps teams lead today’s much-ballyhooed business transformation initiatives, they gain elevated status within companies.

    Perhaps the most critical development has been DevOps teams gaining control over infrastructure, not to mention development and even corporate purse strings. While these teams follow their own best practices, their processes and protocols often don’t align with their organization’s enterprise security model. Additionally, many cloud providers increasingly are working directly with DevOps personnel, circumventing IT, security and business teams. Not only has this eradicated the interdepartmental collaboration that emerged to manage risk following the first generation of internet applications, but traditional IT and IT security processes have been disintermediated.

    The net result is that, even if a company understands the importance of security, no one team or individual is directly responsible for it because those personnel have been disintermediated. This leaves a gaping hole in enterprise cloud strategies, which is due in large part to confusion related to the shared responsibility model in cloud computing. Many organizations incorrectly assume that cloud platform security equates to application security. But, just because a cloud provider is HIPAA-compliant, for example, doesn’t mean an application deployed within that environment is as well.

    We have critical business applications exposed to a brand-new environment—and security is nowhere in sight. Companies are moving forward with cloud migration without fully understanding what their requirements should be or for what the business, IT and security teams are responsible, paving the way for a second iteration of the breach epidemic. Welcome to “Security’s Groundhog Day.” 

    Securing Cloud Migration and DevOps Processes

    We don’t have to make the same mistakes with the cloud that companies made when they first deployed web-enabled applications in-house. We can break the repetitive cycle by making security and risk management a fundamental part of cloud migration and DevOps processes. Here are a few ways to accomplish this:

    • Know your data. Everyone within your organization has a responsibility to understand what types of data are moving to the cloud on a per app basis, as well as exactly what types of controls are required to mitigate enterprise risk associated with that data.
    • Use a matrix of reference architecture to design secure-by-default solutions to meet varying workload requirements. This will help DevOps teams know when to apply more arduous requirements and when lower risk data needs fewer controls.
    • Verify your plans regularly. Agility requires compromises, and the cloud moves quickly. Without continuous monitoring and rigorous testing, you can’t be sure that what you wanted to build actually made it into production.

    Ending ‘Groundhog Day’

    Many companies are forging ahead with DevOps in the cloud without giving security a second thought, and the resulting consequences are giving other organizations pause. In the movie “Groundhog Day,” Bill Murray’s character had to re-examine his life to break the endless time loop. DevOps would be well-served to do the same: to rethink security and make it a focal point in cloud migration and processes. This is how DevOps can avoid repeating the mistakes of the past. Most importantly, there needs to be a change in the DevOps mindset.

    Security should not be the reason organizations are saying “no” to cloud adoption. When engaged as part of the process, it actually becomes the key to unlock the cloud. Making security part of the process is how you avoid “Groundhog Day”!

    — John Turner

  • A Crash Course in Continuous Testing

    A Crash Course in Continuous Testing

    What better way to start a blog on continuous testing than with this “I Love Lucy” clip, and then an analogy:

    https://youtu.be/8NPzLBSBzPI

    Like Lucy and Ethel, many software testers have been scrambling to keep pace with accelerated processes—then along comes the supervisor saying, “You’re doing splendidly … Speed it up!”

    This ever-increasing pace is just one of four aspects of the “perfect storm” driving the need for continuous testing.

    What is Continuous Testing?

    Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain feedback on the business risks associated with a software release candidate as rapidly as possible.

    Why do we need to rethink our approach to testing?

    The expectations associated with test are changing–but legacy testing platforms aren’t keeping up. Legacy testing platforms take a “heavy” approach to testing. They rely on brittle scripts, deliver slow end-to-end regression test execution and produce an overwhelming level of false positives. As a result, they’ve achieved limited success with test automation. The overall test automation rate is 18 percent, on average–8 percent for enterprises. In a polling question, the audience confirmed that the results of test automation have been so-so, at best.

    Now, software testers are facing increasingly complex applications, delivered at dramatically accelerated paces—and they’re expected to deliver trustworthy go/no-go decisions at the new speed of modern business. More of the same won’t get us there. We need to transform the testing process as deliberately and markedly as we’ve transformed the development process.

    The Differences Between Test Automation and Continuous Testing

    There are three main differences between test automation and continuous testing:

    • Risk
    • Breadth
    • Time

    Risk: Exposing more and more innovative functionality to the user is now a competitive differentiator—but it also increases the number, variety and complexity of potential failure points. Most tests are designed to provide low-level details on whether user stories are correctly implementing the requirements—not high-level assessments of whether a release candidate is too risky to release. Would you instantly stop a release based on test results? If not, your tests aren’t properly aligned with business risks.

    Breadth: Just knowing that a unit test failed or a UI test passed doesn’t tell you whether the overall user experience is impacted by recent application changes. To protect the end user experience, you need tests that are broad enough to detect when an application change inadvertently impacts functionality which users have come to rely on.

    Time: If your organization has adopted DevOps and is performing continuous delivery, software may be released hourly—or even more frequently. In this case, feedback at each stage of the process can’t just be “fast”; it must be nearly instantaneous. If the business wants to minimize the risk of faulty software reaching an end user, you need some way to achieve the necessary level of risk coverage and testing breadth—fast.

    What Are the Key Points of Continuous Testing?

    • Continuous testing’s primary goal is assessing business risk coverage.
    • Continuous testing establishes a safety net that helps the team protect the user.
    • Continuous testing requires a stable test environment to be available on demand.
    • Continuous testing is seamlessly integrated into the software delivery pipeline and DevOps toolchain.
    • Continuous testing delivers actionable feedback appropriate for each stage of the delivery pipeline.

    You can find a more extensive list (14 points) at the What is Continuous Testing page.

    Where Can I Learn More About Continuous Testing?

    Watch the complete continuous testing webinar to get more details on the above topics and also learn:

    • How continuous testing impacts the organization
    • What practices testers need to know to be successful with continuous testing
    • How non-automated practices such as exploratory testing fit into continuous testing

    If you want to learn more, download the white paper, “Continuous Testing vs Test Automation: What Testers Need to Know” or visit the What is Continuous Testing page.

    — Cynthia Dunlop

  • The Origins of DevOps: What’s in a Name?

    The Origins of DevOps: What’s in a Name?

    Depending on your frame of reference, DevOps will celebrate it’s ninth or 10th anniversary this year. In 2016, RightScale’s “State of the Cloud Report” estimated that 70 percent of SMBs were adopting DevOps methods. Every indication is that percentage has increased since then. As DevOps prepares for its second decade of existence, it might be worth a stroll down memory lane to revisit the origins of DevOps methods—and even the term itself.

    Pre-2007: A Perfect Storm of Events

    Prior to 2007, a series of circumstances came together that would eventually give birth to what we know today as DevOps.

    “Lean manufacturing” was already well-established as a set of best practices for manufacturing. Often branded as the “Toyota Manufacturing Method,” lean manufacturing strives for process optimization across the manufacturing floor. (Sidebar: Toyota leaders were originally inspired by the ingenious assembly line methods introduced by Ford Motor Company.) “Continuous improvement” is the mantra for lean manufacturing and practitioners continually evaluate ways to:

    • Keep inventory at a minimum. Lean manufacturing means minimal inventory on hand: raw materials (materials used to produce goods) and finished inventory (completed products waiting to be assigned to an order and/or shipped).
    • Minimize the queue of orders. Ideally, orders received should move immediately into fulfillment mode. A key metric of lean manufacturing will always be “order to ship” time.
    • Maximize efficiency in the manufacturing process. Process re-engineering and improved automation will marry into a goal to produce goods as quickly as possible. Each station of operation along the way (cut, weld, assemble, test, etc.) is evaluated for inefficiencies.

    In IT, traditional waterfall methods of application development were already giving way to rapid, iterative methods such as agile. “Speed” was the battle cry, even if quality output was occasionally compromised in the pursuit of rapid development and deployment. Similarly, on the operations and infrastructure side of IT, Cloud Computing and, in particular, infrastructure as a service (IaaS) and platform as a service (PaaS) were coming into their own as mature service offerings.

    Finally, a fledgling set of tools classified as “continuous integration (CI)” tools began to emerge. The notion of CI tools was birthed and branded by Grady Brooch back in 1991 in his Brooch Method.

    Related Content:

    DevOps: The Innovation Power Couple

    A Definition of DevOps for the Masses

    2007-2008: A Frustrated Belgian

    Belgian consultant, project manager and agile practitioner Patrick Debois took on an assignment with a Belgian government ministry to help with data center migrations. In particular, his role was in certification/readiness testing. His duties required him to straddle activities and relationships between the application development teams and the operations teams (server, database network). His experiences—and frustrations over the walls of separation and lack of cohesion between application methods and infrastructure methods—planted seeds of discontent for Debois. His desire for a better way would soon lead him to action.

    In 2008, at the Agile Conference in Toronto, Andrew Schafer posted an offer to moderate an ad hoc “Birds of a Feather” meeting to discuss the topic of “Agile Infrastructure.” Only one person showed up to discuss the topic: Patrick Debois. Their discussions and sharing of ideas with others advanced the concept of “agile systems administration.” In that same year, Debois and Shafer formed an Agile Systems Administrator group on Google, with limited success.

    2009: The Case for Dev and Ops Cooperation

    At the O’Reilly Velocity Conference, two Flickr employees—John Allspaw, senior vice president of technical operations, and Paul Hammond, director of engineering—gave a now-famous presentation titled, “10+ Deploys per Day: Dev and Ops Cooperation at Flickr.” The presentation had a dramatic flair to it, as Allspaw and Hammond would role-play the contentious interplay between representatives of  Development and Operations during a typical software deployment, along with all the finger-pointing/blame that goes on, such as, “It’s not my code, it’s your machines!” Their presentation made the case that the only rational way forward is for application development and operations activities to be seamless, transparent and fully integrated. Over time, this presentation has reached legendary status, and is historically viewed as the seminal moment in time for that called out to the IT industry for methods that we now know as DevOps.

    Unable to attend in person, Debois watched the Allspaw/Hammond presentation by video stream. He was inspired, and—at the prompting of others through social media—formed his own conference called Devopsdays in Ghent, Belgium. By this point in time, the term “DevOps” had officially landed in the history books.

    2010: DevOps in the United States

    With a growing constituency, a Devopsdays conference is held for the first time in the United States in Mountain View, California, on the heels of the Velocity annual conference. Fast forward to 2018: There are more than 30 Devopsdays conferences already scheduled for 2018, including dozens across the United States.

    2013: ‘The Phoenix Project’

    For many of us, another noteworthy moment in the history of DevOps was the publishing of the book, “The Phoenix Project,” written by Gene Kim, Kevin Behr and George Spafford. This fictional novel tells the story of an IT manager thrust into a seemingly hopeless situation, as he’s charged with salvaging a mission-critical ecommerce development project that’s gone off the rails. His mysterious mentor, a board member steeped in the disciplines of lean manufacturing, guides the main character into new ways of thinking about IT and application development, introducing the concept of DevOps along the way.

    (Sidebar: The Phoenix Project helped inspire us to write “Outsource or Else!” a similar business fable in which a VP of Software uses DevOps when outsourcing development of a major new product.)

    DevOps for the Future

    It’s reasonable to describe DevOps as a journey, or perhaps an aspiration, rather than defined destination. DevOps, like lean manufacturing, seeks continuous improvement, seeking higher output, greater efficiencies and even continuous deployment. Automated tools that support DevOps continue to evolve.

    Much has been accomplished since the inception of DevOps in the last decade and we expect to see even more in 2018 and beyond.

    — Steve Mezak

  • Third Annual DevOps Dozen Winners Announced

    Third Annual DevOps Dozen Winners Announced

    We are very pleased to announce the winners of the third annual DevOps Dozen Awards. In many ways this year was a watershed year for the DevOps Dozen, as the process of selecting, voting and choosing the winners was much more refined and mature. In each of the 12 (it is a dozen, after all) categories the winners were absolutely deserving of the award and recognition.

    Many thanks to our all-star panel of judges: Jayne Groll, Robert Stroud, Helen Beal, George Hulme and Ericka Chickowski. I was the tie-breaker judge and had to cast a vote in just one category. I should also say that almost all of the categories were very tight. Every one of the finalists was deserving of the recognition!

    These awards are a reflection of some of the great work being done in the DevOps community. They are not exhaustive; there are many, many worthy companies, people, projects and products out there. But here is our take on the best of the best in DevOps.

    So, without further ado, here are the 2017 DevOps Dozen winners:

    Best DevOps Open Source Project

    best open source solution Jenkins is the winner of the Best DevOps Open Source Project for 2017. Originally created in 2004 as a fork of “Hudson,”  Jenkins is one of jenkinsthe leading open source automation servers available. Jenkins has an extensible, plugin-based architecture, enabling developers to create 1,400+ plugins to adapt it to a multitude of build, test and deployment technology integrations. In 2017, Jenkins surpassed 155,000 active installations (these are active installations that report usage back to the Jenkins project—only a fraction of total installations), and approximately 1.5 million users, making it the most widely deployed continuous delivery automation server in the world. Learn more: https://jenkins.io/

    Best DevOps Commercial Solution

    devops dozen commercial solution ElectricFlow from ElectricCloud is the winner of the Best DevOps Commercial Solution for 2017. ElectricFlow is an enterprise-grade DevOpselectric cloud release automation platform that simplifies provisioning, build and release of multi-tiered applications. A shared, model-driven approach to managing environments and applications allows teams to coordinate multiple pipelines and releases across hybrid infrastructure in an efficient, predictable and auditable way using the tools and stacks teams already know and love. Learn more: http://electric-cloud.com/products/electricflow/

    Best DevOps Solution Provider Executive


    devopsdozen SP exec     The winner in this category was actually a 1/1a entry of the CloudBees team of CEO Sacha Labourey and CTO Kohsuke Kawaguchi. Sacha’s Sacha and KK Cloudbeesbackground prior to CloudBees was as CTO and key person at JBoss. KK was a Sun engineer when he first became involved with Hudson and later founded Jenkins. Together, they have built CloudBees into a powerhouse in the DevOps and CI/CD space. While working closely with the Jenkins community, they also have been instrumental in the continued growth and popularity of the Jenkins project. Together, they are a formidable team worthy of this award!

    Best DevOps Solution Provider


    DD best devops solutions provider     CA Technologies, which now includes Automic, BlazeMeter, Runscope and Veracode, is the winner of the Best DevOps Solution Provider for 2017. From a toolchain perspective, CA Technologies provides the widest array of highly automated solutions necessary to build and optimize integrated workflows across application development, delivery and operations. Spanning the entire application life cycle—including planning, development, testing, release and operations—only CA Technologies offers the full range of capabilities needed to deliver secure, quality applications quickly with an unparalleled customer experience.

    Most Innovative DevOps Solution of the Year

    most innovative devops solutionThe Most Innovative DevOps Solution of the Year 2017 goes to Habitat from Chef, the leader in Continuous Automation. Habitathabitat is a SaaS-based service that provides the fastest way to package apps simply and consistently for deployment and management across flexible cloud-native architectures such as those comprising Docker Swarm, Kubernetes and Cloud Foundry, both on-premises and in-cloud. Habitat gives developers and operations teams complete control over the containerized application life cycle. Learn more: https://www.habitat.sh/

    Best DevOps Evangelist


    devops evangelist    Derek Weeks VP and DevOps Advocate at Sonatype (co-founder of All Day DevOps) is the Top DevOps Evangelist for 2017. This year All Day DevOps offered 100 free onlinederek weeks sessions led by DevOps practitioners to 33,000 professionals around the world. Since its founding, the community has attracted, educated and supported more than 40,000 DevOps professionals. The conference also brought attention to more than 250 DevOps-related communities, meetup groups and organizations that are helping to educate practitioners around the world. In 2017, Derek delivered 18 DevSecOps-related keynote addresses, conference speeches and meetup presentations in the United States and Europe. He also produced more than 75 DevOps-related blogs over the year, covering topics from continuous delivery to DevSecOps, modern infrastructure and cultural transformations. The blogs not only delivered first-hand experiences, but also highlighted the work of more than 40 DevOps practitioners from different companies around the world.  The blogs can be seen at Sonatype, All Day DevOps, DevOps.com and Dzone. In addition, Derek championed a number of DevOps reports and surveys in 2017, including the “State of the Software Supply Chain Report” and “2017 DevSecOps Community Survey,” to shed light on industry best practices and areas in need of attention or evolution.

    Best DevOps Transformation


    devops transformation    CapitalOne was the judges choice for Best DevOps Transformation for 2017. Over the past few years, the 20-year-old financial services giant capital onehas been transforming itself, tapping DevOps to establish a continuous software delivery cycle. Topo Pal, a senior director and senior engineering fellow, told a packed room at the recent DevOps Enterprise Summit in San Francisco the company’s journey suits its entrepreneurial spirit. “We consider ourselves a startup, and like any startup, we have different DNA,” said Pal. “For instance, we build our own software.” All the better for adopting DevOps. The company does just about everything (including back-end processing) in the public cloud now, with a focus on building microservices using open source technologies. Having spent the previous three years building out automation steps, scaling DevOps, adopting open source and cloud and starting to measure its success, Capital One is now turning its attention to continuous delivery. Learn more:

    Best DevOps Transformation Leader


    devops transformation leader    Paula Thrasher is the winner of the Best DevOps Transformation Leader for 2017. Paula is Director of Digital Services at CSRA Inc. Paula paula thrasher Thrasher has 20+ years experience in IT and has spent the last 15 years trying to implement Agile culture in the federal government. Her first Agile project was in 2001; since then, she has led more than 15 programs and projects as an Agile developer, technical lead, Scrum master or Agile coach. Her teams have helped two federal agencies migrate applications to Amazon AWS GovCloud and done some other amazing DevOps ninja work along the way. Paula is also the executive lead for CSRA’s corporate giving group’s search for a STEM charity and joined forces with Girls Who Code to bring summer programs and after-school clubs focused on closing the gender gap in IT. She also participated in the DevOps Forum 2017, co-authored a paper on DevOps learning in organizations,”Continual Learning: Building a DevOps inspired Career Track,” and peer reviewed other paper topics produced by the forum this year. Paula has spoken publicly at multiple industry conferences including AllDayDevOps  2017, Red Hat Government Symposium and DevOps Enterprise Summit 2017.

    Best New DevOps Solution Company

    nClouds is a provider of DevOps and cloud services, products, and solutions, specializing in modern infrastructures on AWS — and winner of Best New DevOps Solutions Company for 2017. They work as an extension of their customers’ teams to build and manage modern infrastructure solutions that deliver innovation faster. nClouds is a certified AWS Advanced Consulting Partner with 250+ DevOps AWS implementations, 500+ deployed pipelines, and 10,000+ managed servers. They call their new SaaS offering, nOps, modern change management at the speed of DevOps. nClouds was named to CIOReview “20 Most Promising DevOps Solution Providers – 2017” and “20 Most Promising IT Service Management Providers – 2017”.

    Best DevOps Book/eBook

    best DevOps“The DevOps Adoption Playbook” by Sanjeev Sharma of IBM won the Best DevOps Book Award for 2017. The book lays out a clear “how-to” devops adoption playbookfor DevOps, including topics such as value stream mapping, how to lead the transformation of culture and scaling DevOps to the enterprise. As Sanjeev himself says, the book started from a Powerpoint deck of best practices he created to take in everything he had learned.

    This book represents the culmination of years of learning by not only Sanjeev, but by IBM in general, and includes some of the leading names in DevOps that he learned from during this time. Sanjeev also stays true to the “playbook” paradigm, making references to cricket, soccer and other sports throughout. It is a good read and well-organized. To learn more, listen to this DevOps Chat: ‘The DevOps Adoption Playbook’ by Sanjeev Sharma.

    Best DevOps Presentation of the Year

    devops presentation“DevOps: The New Reality for Enterprise Transformation,” a 45-minute keynote presentation at IBM InterConnect 2017, is the winner of the Best DevOps Presentation for 2017. It features Gene Kim, John Comas, NBCUniversal and IBM execs and  distinguished engineers including David Lindquist, Angel Diaz, CJ Paul and Michael Elder. Are you dabbling in DevOps? Maybe you’ve run a great pilot project or have a terrific two-pizza team that’s innovating new apps. How do you scale their success to your whole organization? The answer lies with a combination of cultural, personal and technical transformations that blend methodologies and cloud-native approaches with proven automation patterns and existing on-prem development. The presentation includes client stories and demonstrations of the latest IBM solutions to help companies transform their teams and build, deploy and manage their apps for large-scale enterprise IT environments.

    Best DevOps.com Article of the Year

    “Continuous Integration vs. Delivery vs. Deployment: What’s the Difference?” by Chris Tozzi won the Best DevOps.com Article of the Year devopsy.kinsta.cloud articleAward for 2017. Christopher Tozzi has covered technology and business news for nearly a decade, specializing in open source, containers, big data, networking and security. He is currently Senior Editor and DevOps Analyst with Fixate.io and Sweetcode.io.

    Again congratulations to the winners—well-deserved recognition for all of your efforts.

    For those interested in next year’s DevOps Dozen, information will be out in July or August of this year.

    — Alan Shimel

  • A Definition of DevOps for the Masses

    A Definition of DevOps for the Masses

    If you asked the average person in the street, “What does DevOps mean to you?” you’d probably get a blank stare. And there are those who aren’t directly involved but are vaguely aware of DevOps as a concept. While a vague understanding is better than nothing, it leaves room for misconceptions and misinformation, which can be problematic in the long term. An accurate definition of DevOps is necessary.

    How can you provide an accurate definition of DevOps for a non-technical audience? Long-term DevOps practitioner Alex Honor echoed earlier agile software development principles when he coined the phrase, “People over process over tools.” This mantra provides a handy list of DevOps priorities, and as such offers a useful framework for an easily understandable definition of DevOps.

    Start with the People

    Everyone loves a good organizational chart, and discussing how DevOps teams organize themselves is a useful way to understand how DevOps should work in practice. DevOps is very much about bridging traditionally separate development and operations departments, but this involves more than simply increasing collaboration between teams.

    Related Content:

    5 Biggest Ways to Fail at DevOps

    DevOps Gets More Exciting in 2018

    In a traditional setup, developers build applications and fix them when necessary, while operations teams work to maintain, support and monitor those applications.

    In DevOps, the wall dividing these two worlds disappears. But it’s not just about getting dev and ops teams to work more closely—it’s about creating an environment where developers and engineers work alongside each other at every stage of a product’s life cycle. In other words, there should be no separation between dev and ops, just a unified DevOps team.

    By emphasizing the people factor and contrasting a DevOps team structure with more traditional arrangements, it’s easier to visualize DevOps playing out in the real world. This is a great place to start when it comes to demystifying DevOps for a less-technical audience.

    Move on to the Process

    When put into practice, DevOps is supposed to be faster, more efficient and more reliable than more traditional software engineering methodologies—once the organizational structure is in place, these benefits can be achieved via innovative DevOps processes.

    In traditional development and ops, manual tasks have a habit of slowing down processes, and getting in the way of high-frequency deployments. But in DevOps processes based on infrastructure as code (more on the tech later), teams can automate the provision and management of resources.

    Take the task of provisioning server resources, for example. In the past, the developer would email the infrastructure team and ask for a certain set of resources in a specific configuration. Then someone in the infrastructure team would look at a document and follow a checklist of tasks before finally deploying the server.

    In a DevOps process, not only are developers and infrastructure engineers working alongside each other in the same team, they’re also implementing processes through infrastructure as code (IAC).

    Within the context of IAC, the provisioning of IT resources is automated via code, so rather than provisioning servers manually, the developer simply clicks a button. The desired infrastructure then spins up automatically, accelerating the overall process and giving DevOps teams the means to deploy far more frequently and efficiently.

    By describing the automated processes made possible by IAC, the differences between DevOps and more traditional practices become much clearer. For less-tech-savvy employees, this explanation provides some much-needed context in terms of the day-to-day working of DevOps teams.

    Then Talk About the Tools

    Technology, and the benefits it brings in terms of automation and management, is a key driver of DevOps. The maturation of cloud computing and virtualization, and the emergence of infrastructure as a service (IaaS) in particular, provides the flexibility and speed demanded by DevOps.

    With IaaS, it’s possible to instantly provision computing resources for highly customized and constantly shifting IT requirements, without on-premises hardware or manual configuration. This in turn enables the infrastructure as code (IaC) processes detailed above, and the level of automation required for DevOps teams to function.

    So cloud computing, in the form of IaaS and by extension IAC, lays the technological foundations of DevOps. That’s the big-picture stuff, but what about those brand-name tools that non-technical people might have actually heard of? Docker, Kubernetes, GitHub, Jenkins, Travis CI … the list goes on, but how vital are these to the core concept of DevOps?

    Arguably, not very. While containerization, source control and continuous integration tools all can perform very important roles within a DevOps context, they’re hardly defining features of DevOps itself.

    Continuous configuration automation solutions such as Puppet and Chef come more directly under the IAC umbrella, enabling the automatic configuration and scaling of data center resources. But like the others, these tools would be equally at home in a more traditional setup.

    In this sense, there’s no such thing as a “DevOps tool,” just tools that can be used within a DevOps organization for DevOps processes. It’s how you use them that really counts.

    So when offering a definition of DevOps for a novice audience, don’t fall into the trap of simply reeling off a list of tools. DevOps is far more about people, organization and process. And while it’s very reliant on IaaS and IAC technologies, many of the tools utilized by DevOps teams are more or less incidental.

    And Finally, a Reminder that DevOps Works

    The ultimate goal of DevOps isn’t simply to unify development and operations, but to result in shorter dev cycles, more frequent deployments, higher-quality products and happier customers. More bluntly, the ultimate goal of DevOps isn’t just to say, “We do DevOps,” but to increase productivity and make the business more profitable.

    Just look at sprawling organizations such as Google and Amazon. The success of these companies hinges on their ability to deploy new software multiple times every day, or even every hour. Amazon and Google may not agree on a precise definition of the term, but what they do agree on is that DevOps, as a set of unified software engineering practices, is crucial to their profitability.

    With a consensus on the broad strokes of DevOps emerging over the last few years, lack of definition of DevOps will hopefully become less of an issue as its culture crystallizes. In the meantime, the good news is that the big ideas behind DevOps are also the most straightforward to explain to a non-technical audience.

    By breaking DevOps down into people first, process second and tools third, an accurate and relatively simple definition of DevOps is possible. DevOps is fundamentally about people, how developers and engineers organize themselves and work as a unified team to deliver better products faster. It’s on top of this structure that DevOps processes are built, with a heavy focus on automation and innovative tools—always within the context of the core DevOps principles and practices.

    — Neal Thoms

  • 5 Reasons AWS Service Catalog is Sexy for DevOps and Cloud

    5 Reasons AWS Service Catalog is Sexy for DevOps and Cloud

    Ok, so you’re probably more excited about topics such as microservices and containers right now, but bear with me. AWS Service Catalog is becoming increasingly necessary as cloud infrastructure evolves, allowing IT and developers to share pre-approved services, which helps tear down silos and encourage DevOps-related practices.

    If you’re not familiar with Service Catalog, it allows organizations to create, manage and share catalogs of IT products and services that are approved for use on AWS. You can share simple services, such as an Amazon S3 bucket, or more complex services, such as a multi-tier application containing an auto-scaling group and Amazon RDS with Amazon DynamoDB tables. Amazingly, the end user can provision these services without knowing the complexity behind the AWS services, and if you wanted, without needing write permissions to AWS (more on this later).

    Further, Service Catalog is built on top of AWS CloudFormation, which means that when you design services and follow security best practices and run time, you can add constraints such as controlling instance sizes (I know, everyone loves to launch the biggest instances).

    In this blog post, I’ll share five reasons why you should consider making Service Catalog part of your DevOps and cloud strategy right now.

    Improved Security

    As a sysadmin 10 years ago, I remember our department had full control of bringing all new resources to the infrastructure. We’re fortunate that’s no longer the case and its typical for developers to provision resources.

    Provisioning resources on AWS has never been easier, but many developers who can provision resources have limited understanding of the AWS shared security model. For example, a recent Uber hack was due to someone checking the keys to GitHub. What’s more, the steady and impressive flow of new services from AWS makes it even more difficult to know and follow security best practices for provisioning resources for various services.

    Service Catalog can help improve security. Here’s how:

    • Have developers provision resources without having access to AWS. Yes, you read that right: You can add constraints regarding which IAM role should be used to provision resources.
    • Build your service catalog on top of CloudFormation, which means you can follow the security best practices once, such as enabling data encryption at rest encryption for S3. So, when your users provision resources, all these best practices are applied.

    Cost Savings

    In Service Catalog, you can add constraints on the size resource allowed for provisioning (love the extra-large instances). Your developers can still provision resources, but they’re not going to break the bank. And your CFO will love you for that.

    Using constraints you can control instance type to be either t1.micro or m1.small

    Centralized Management of Service Catalog Across Accounts for Better Compliance

    Although Service Catalog is built on top of CloudFormation, unlike CloudFormation it’s designed for sharing commonly deployed applications to promote collaboration. This means you can share the service catalog across multiple accounts and have the same constraints copy over. Here’s a great article on how to do that.

    Productivity Gains

    Most often I work with companies on Service Catalog to increase productivity. One of the common objections I get is, “We’re not ready for this level of standardization because our infrastructure is changing so fast—we’re in rapid change mode.” Fair enough! However, even during this rapid development phase, your developers are most likely, individually rather than collectively, working on standardization to increase productivity. As an example, let’s say I normally launch a test server that updates the security group with access to VPN. Chances are there are other developers taking similar actions by writing their version of scripts. This is precisely where Service Catalog helps, by providing the platform to share these types of services (such as launching a server with VPN access only) to other employees, which, in return, improves team productivity.

    Facilitating DevOps Culture

    A principal objective of DevOps is to break down silos and align team members around delivering customer value. Service Catalog encourages a culture of sharing and collaboration by instantiating it into practice.

    What’s Next?

    I’m excited about the capabilities of Service Catalog and its promise for DevOps teams. At nClouds, we’re taking our use of Service Catalog to the next level by integrating an approval process to govern provisioned services, and automating the workflow as part of the change management process. Automation and just-enough lightweight process provide the control needed, but without sacrificing DevOps speed. You can read more in this new white paper, “Modern Change Management for AWS.”

    Also, for more information about Service Catalog and DevOps in practice there are some great presentations from AWS re:Invent available for replay: financial services FSV308, Fannie Mae MSC201, and John Wiley & Sons DEV321.

    — JT Giri

  • SolarWinds Acquires Loggly to Add Analytics to DevOps Portfolio

    SolarWinds Acquires Loggly to Add Analytics to DevOps Portfolio

    An ongoing SolarWinds effort to drive down the cost of implementing DevOps has been extended by acquiring Loggly, a provider of log analytics software provided as a cloud service.

    Christoph Pfister, executive vice president of products at SolarWinds, says the Loggly service rounds out a portfolio of DevOps offerings spanning application and infrastructure monitoring, website monitoring and log management software.

    In keeping with the company’s overall DevOps strategy, SolarWinds will provide access to Loggly at substantially less cost than rival log analytics platforms such as Splunk, Pfister says. Pricing for the Loggly service starts at $99 per month. In contrast, other log analytics platforms charge IT organizations based on the amount of data being analyzed, which results in many of them limiting the amount of log data they analyze because of cost concerns.

    IT organizations have been making major investments in log analytics to more proactively discover anomalies indicative of either potential application performance issues or security breaches. The more log data being analyzed, the more accurate the analytics being applied to those logs becomes. The goal should be to make data science capabilities as broadly available as possible, says Pfister.

    Next up, Pfister says SolarWinds will be working on unifying the user interface experience between Loggly and the rest of its DevOps portfolio. In addition, SolarWinds is examining whatever opportunity there may be to bundle various cloud services together in a single suite of offerings, says Pfister.

    Log analytics has emerged as a foundational component of both DevOps and, by extension, digital business transformation. Developers are keenly interested in being alerted to events that might have a potential impact on their applications before they occur. IT operations teams, of course, are relying on analytics to enable them to be more proactive when it comes to making sure IT infrastructure resources are continuously available. At the same time, business users are discovering that log analytics can provide them insights into events that are indicative of how, for example, end users are employing new capabilities that have been added to a website.

    While most IT administrators have a lot of experience hunting through logs looking for specific events, the sheer volume of data in those logs prevents most of them from gleaning anything that approaches actionable intelligence. Advanced analytics applications provide the means through which all the log data being collected becomes more valuable to the business.

    As it becomes more affordable for more IT organizations to apply monitoring and log analytics, the number of IT organizations embracing DevOps practices should increase. Having access to tools, of course, is only one part of the equation. But most organizations wind up backing their way into DevOps, starting with tools that provide them additional capabilities and insights. Once they master those tools they begin to apply the knowledge and insights they gain to implement more sophisticated DevOps processes. For many IT organizations, however, the cost of acquiring those tools to get started down the path to DevOps has simply been too high.

    — Mike Vizard

  • Dissecting the Role of QA Engineers and Developers in Functional Testing

    Dissecting the Role of QA Engineers and Developers in Functional Testing

    Until a few years ago, quality assurance was generally considered low-level R&D. As a result, quality assurance (QA) teams were characterized by a low budget, lack of attention and, more often than not, poor attitudes. Moreover, QA engineers were considered the enemies of developers and the product.

    However, today, this is no longer the case, and QA is part of the entire software life cycle. Today, organizations understand how a product’s quality affects the brand’s reputation and customer retention. In the Agile ecosystem, QA engineers are no longer solely focused on testing; they also fill an important role in the planning and delivery domains. The shift left approach—where testing is performed earlier in the life cycle—requires QA engineers to have higher technical abilities and involvement in the whole CI/CD process. Nevertheless, QA managers, who usually encourage assimilation in the scrum team, as well as rapid feedback for user stories and automation, must not forget the main objective of quality engineers: to ensure a high-quality product and a seamless user experience for customers.

    High quality demands testing and verifications. There are different types of testing that can be conducted to meet quality goals. In one of its blog posts, Testing Excellence describes almost 60 types of testing that can be performed on a product. We’re going to look at one that is quite clearly one of the most important types of testing: functional testing.

    Different than other forms of testing, functional testing is considered one of the most sophisticated test type, and the most comprehensive one.

    Same Team, Different Responsibilities

    One important fact every QA engineer must remember is that developers develop and QA engineers test. Even though QA and developers are part of the same scrum team, their work, methodologies and state of mind are completely different. In cases in which the significant contribution of QA isn’t visible to the whole team, testing might be considered an easy and clear task. Quite the contrary; testing an application is much more complicated and entangled than developing it. When planning tests and executing them, QA engineers must take into account several aspects developers likely never consider.

    Understanding How the User Thinks

    The primary distinction between dev and QA is state of mind. While developers write pieces of code that later become features in the application, QA is expected to understand how real users think, engage customers to learn business scenarios, and confirm that the application satisfies customer needs.

    Let’s look at eBay, for example. Every veteran R&D member will agree that eBay isn’t just a simple shopping application, but a comprehensive system that includes a whole set of capabilities on both web and mobile that requires attention and deeper understanding to determine whether they really function correctly. In such a rich and mature online platform, we can identify several types of users and many cases in which the application may be utilized. A seller performs different steps than a buyer and requires different functionality, while a support agent needs an entirely different version of the application. When planning tests, all these personas must be taken into consideration with a particular test plan for each. In other words, testing functionality is not just simulating user operations.

    In addition, eBay is not a standalone application—its web application lives inside the browser and subsequently depends on that browser’s rules and behaviors. This is true for eBay’s mobile apps, as well, which must meet the OS constraints to function correctly, whether it’s navigating to the seller’s store or making a purchase. This makes compatibility testing an integral part of functional testing. Most developers don’t think about the project availability matrix when they code, so QA is required to contemplate all the ways the customer will engage with the application and verify functionality for each.

    Viewing the Application as a Whole

    Dev and QA differ in their point of view—an obvious but important distinction. While developers focus on developing user stories, QA engineers test the user story, the feature it is part of and the application behavior with the new code. Integration testing is a crucial part of the application verification effort and requires a broader view of the application and how the new functionality is part of it. End-to-end testing is the fulfillment of the above two aspects, validating that real user scenarios in the context of multiple regions in the application behave as expected. End-to-end tests increase test coverage and reduce the risk of making the new code part of the application.

    Paying Attention to User Experience

    As noted, testing the application functionality is merely one step in functional testing. Testing the operations available in the application encompasses another type of testing—the user experience. If a new feature is developed, but users do not have easy access to it or cannot understand how to use it, it is as if the feature doesn’t exist. QA engineers must incorporate user experience as a main metric of features so users will not have room for error, which can lead to misuse and frustration.

    For instance, eBay’s “all categories” page previously displayed all the categories by default, even though some of the categories had no items. While this was the correct behavior from a functionality standpoint, it caused user confusion and mistrust. Consequently, the “all categories” view was changed to show only categories with items.

    Looking at the narrow current task, developers might implement features as they are told without questioning or contemplating the specifications. In the same way, testers who test features without realizing how customers perceive them are missing an important benefit of the test.

    The above three aspects—thinking like customers, testing the application as a whole and paying attention to user experience—revolve around the way developers and QA engineers relate to new features. While developers tend to follow the specification guidelines, QA engineers must “think outside the box” when it comes to user consumption of the feature.

    There are two other ways in which QA work is more complicated and yet invaluable—test maintenance and test automation.

    Maintaining High Quality Throughout an Efficient Release

    In general, developers split their time between developing new features and fixing defects. QA work is much more diverse. A substantial portion of the release is spent on testing functionality that already has been released and used. While the main effort of designing and writing test plans for this functionality was invested in past releases, every new feature developed requires a test plan and a maintenance effort on existing tests. One of the main goals for QA managers is reducing this effort to a minimum. Teams that succeed in creating clear and reusable tests simplify the maintenance struggle and optimize the test registration time.

    Eliminating Risk Through Automation

    However, for QA, the most cost-effective solution is test automation. At release end—the time when QA is at its most stressed and every commit might introduce a new risk—automation testing can eliminate risk and supplies early feedback on every change. Agile teams strive for the highest automation coverage percentage so the development team can have confidence in committing changes late in the release. That said, developers often aren’t interested in investing their time in automation. They support the QA automation effort, but they don’t want to “dirty their hands” by doing testing. Whether it’s UI automation—during which achieving element uniqueness is essential yet tricky and requires developers’ intervention—or API testing for APIs without proper documentation, QA faces intricate challenges that require sophisticated solutions, which developers are, in most teams, not part of. While the dev team focuses on the status of the new feature, QA attends to the application as a whole with extra attention to identify regressions created by a change.

    Join Forces for Higher Rate of Success

    Testing an application requires a completely different mindset than developing it. One of the main challenges in the Agile methodology is to create developer awareness of quality, involving other stakeholders in the quality assurance activities and making the QA process visible to everyone. QA managers must understand how day-to-day QA work is different than the work of other team members so they may truly represent the complexity, efforts and eventual success. R&D groups that join forces and understand that QA extends far beyond the actual tasks of the QA team have a much higher chance of improvement and set high standards for their product’s quality. Implementing the appropriate methodologies and utilizing the right tools lead to an increase in customer satisfaction and retention rate.

    About the Author / Ronit Eliav

    Ronit Eliav is the Director of Product Marketing at Panaya. With a deep interest in digital transformation and the latest IT trends, she enjoys creating thought leadership around such topics as agile and continuous delivery, DevOps, quality assurance and IT modernization projects. Connect with her on LinkedIn.

  • DevOps Challenges in C/C++ Projects

    DevOps Challenges in C/C++ Projects

    “C++ is not only the most powerful language in terms of performance, but it’s also a great language! It has true generics, it is expressive, and one of the most loved languages out there by programmers.”

    — Diego Rodriguez-Losada, SW Engineer at JFrog and creator of Conan.io

    This very powerful language that has unbeatable performance continues to be used and favored in all industries. However, while DevOps has become pervasive in other major domains of software development such as Java, implementing modern C and C++ DevOps hasn’t been easy, despite solutions out there that can actually help.

    Let’s take a look at the challenges C/C++ developers face, and then see how they can be solved.

    tl;dr

    C and C++ are are favored by many developers for many great reasons. However, implementing modern DevOps and continuous integration in C and C++ projects isn’t easy. It is still challenging due to the nature of the C/C++ programming languages and ecosystem. Today, we have the knowledge and experience to identify the requirements we need to meet today’s DevOps needs for C and C++. And I’ll demonstrate with the below case study that this is possible.

    Building C and C++ Projects

    Ideally, we want the CI/CD flow from the developer changes to production to be as smooth and fast as possible. However, when compared to other development languages, C/C++ developers face greater challenges:

    • Long build times: This is not because C and C++ compilers are slow. In fact, they are blazing fast and some of the most advanced and brilliant pieces of technology in the whole IT world. But, C/C++ have the problem of headers and the preprocessor basically copying every included file again and again in each translation unit, bloating the lines of code that they have to compile. There are some mechanisms as pre-compiled headers that can partly alleviate the issue for second and subsequent rebuilds. Also, C/C++ languages are used many times for huge projects compared with other languages, with millions lines of code (MLoc)—a typical AAA game has 20 MLoc.
    • Diverse platforms and ecosystems, different build systems: C and C++ are ubiquitous. They are used in computers, embedded devices, mobile devices and more. But in every platform they will use different compilers (such as MSVC cl.exe in Windows, GCC in Linux, apple-clang on OSX) and with many different build systems. CMake, MSBuild and Makefiles or autotools are widely used, but companies are also using many other build systems, even developing their own custom solutions.
    • Binary compatibility: C and C++ are built to native/binary code, but binaries compiled with a certain compiler version are not compatible with other compilers, or even with the same compiler of a different version. This problem is known as ABI (Application Binary Interface) incompatibility, which other languages don’t have to deal with. ABI incompatibilities can result in link errors, which are easy to catch at build time, but oftentimes can produce runtime errors.
    • Code inlining and embedding: Shared libraries directly embed native code of static libraries they are linking. But not only that, even static libraries might embed code declared in headers from another library. This means it might be necessary to rebuild binary artifacts from source code libraries that have not been modified at all, just because some of its dependencies have changed.
    • Lack of standard for OSS: OSS libraries can host their source code in GitHub, GitLab or Bitbucket, but that doesn’t make them ready to use. Users need to build binaries from sources (which can be painful), retrieve prebuilt binaries from a system package manager (which may be obsolete and in any case different for each platform) or by using other installers or precompiled modules (which must be downloaded from a website). After that, they typically also require different tweaks to the consumer build system, which is also different for each platform.

    Modern DevOps Requirements for C and C++

    Given the above list of challenges, what are the modern DevOps practices and tool requirements for C and C++ projects?

    • Manage and reuse binaries: Building from sources every time is very expensive, error-prone and doesn’t scale for large projects. Reusing binaries should be consistent for different platforms, and deal with the ABI compatibility issues.
    • Manage all binaries in a single repository or server: Creating and maintaining packages in several systems (such as apt in Debian, rpm in RH, nuget/choco in Windows and pkg in OSX) is very costly for developers or DevOps engineers. Being able to store, manage and retrieve binaries from the same location is a great simplifier of infrastructure and flows, thus a big time saver.
    • Adapt to any build system, platform and tool, from legacy to latest: Creating good CI and package management would be much simpler if everyone was using a single build system. But thinking projects can migrate to a build system is plainly naive. The cost of migrating some libraries or projects to a new build system is a huge investment that can take months. Processes and tools must be able to adapt to to deal with any build system and existing legacy tool.
    • Have good integrations with other tools: Not only build systems, but tools must integrate as simply as possible with other kinds of tools. For example, continuous integration platforms such as Travis and Appveyor cloud services for Linux/OSX and Windows, popular for being free for OSS projects, as well as Jenkins, which is the de facto standard in the industry for proprietary code. Also tools must integrate well with popular IDEs such as Visual Studio or XCode and testing, coverage, static analysis, multiple control version systems, etc.

    Conan C/C++ Package Manager Case Study

    Conan is a free OSS C/C++ package manager. It is decentralized, portable, and multi-platform, running on many operating systems, such as Windows, Linux, Mac, BSD and Solaris, but targeting any possible target of C/C++ applications.

    Here’s how Conan addresses the above requirements:

    • Conan is able to build, upload, and share binaries for any number of different configurations. It manages binaries, retrieving the correct one for each corresponding platform as needed, and is also able to build from sources when necessary, minimizing ABI incompatibility issues.
    • Conan packages and pre-built binaries can be uploaded to a server and shared within They can be shared privately within a team or companywide, using the OSS conan_server or JFrog Artifactory Pro. If desired, Conan packages can be distributed worldwide using JFrog Bintray either with private or public repositories, completely free for OSS projects. All different binaries for all supported platforms can be uploaded and managed in the same server with exactly the same interface.
    • Conan works with any build system. It includes built-in integrations with CMake, Visual Studio, Makefiles, SCons, QMake and more. It also has good user-side extensibility to support any other build system, using “generators.” This means extensions can be developed to translate the Conan dependencies model to any build system format and generate files that can be read by those build systems.
    • Conan integrates well with different CI systems, with specific tools and helpers for Travis, Appveyor and GitLab, and also features custom DSLs in the Jenkins Artifactory Plug-in.

    Conan package recipes are written in Python, so they can be used to easily customize behavior to a great extent with standard Python syntax, allowing users to easily plug-in many different tools that were previously mentioned in this article: static analysis, testing, code coverage, and more.

    Let’s take a look at a typical flow, from a DevOps perspective, to illustrate how Conan works. First, a developer makes some source code changes to a specific library (LibB), committing and pushing these changes to the shared version control system server (Git Repo).

    Diagram: CI Cycle example for C/C++ with Conan, Artifactory and Jenkins (build systems: CMake, VS, MakeFile)

    Then the CI system will listen to the Git repository, ideally with Git hooks since polling is not recommended, and fire a job for it (Jenkins). Below is an example of how this would be defined with a Jenkins pipeline:

    The first stage in the above example is straightforward. The second stage invokes the package creation that is internally split into the two subtasks:

    1. The LibB dependencies are retrieved in binary form, to avoid rebuilding them from sources and wasting time.
    2. The dependency graph for all transitive dependencies is built and one or more files are written. In this example, LibB uses CMake as the build system and Conan generates a “conanbuildinfo.cmake” file that includes all of the dependencies information to enable LibB find and correctly link to them. Conan will then call the LibB build system to generate a binary package for it. And finally, in the last Jenkinsfile stage “Upload packages,” the generated binary is uploaded to the Conan package server (JFrog Artifactory). The LibB binary package is immediately available for consumption by developers or other CI jobs.

    This example illustrates a build configuration for a 32-bit architecture as specified in the  “conan create” command with the “-s arch=x86” argument. Note that many additional configurations can be built in parallel using parallel tasks and jobs for different compilers, OS, architectures and more.

    Conclusion

    C and C++ have extra challenges compared to other programming languages in development. This also makes it more challenging when trying to implement modern DevOps, but not impossible. C/C++ has been overlooked and it’s time we update the tools to meet the needs of developers. What DevOps principles and practices are you implementing with your C/C++ projects?

    About the Author / Baruch Sadogursky

    Baruch Sadogursky is the Developer Advocate at JFrog. For a living he hangs out with JFrog’s tech leaders, writes code around the JFrog platform and its ecosystem, and then speaks and blogs about it all. He has been doing this for the last dozen years or so, and enjoys every minute of it. He also is a professional conference speaker on DevOps, Java and Groovy topics, and is a regular at the industry’s most prestigious events including JavaOne (where he was awarded a Rock Star award), DockerCon, Devoxx, DevOps Days, OSCON, Qcon and many others.  His full speaker history is available on Lanyrd. Follow him on Twitter @jbaruch on Twitter, or read his blogs here and here.