After weeks of speculation and rumor, Microsoft has agreed to acquire GitHub, the hosting service for version control using the Git version control system developed by Linux creator Linus Torvalds, for $7.5 billion. There are various views on why this move may not work, but here are several reasons why a Microsoft GitHub combination makes sense.
Microsoft is big on open source
One reason why this deal makes sense is that Microsoft is the biggest single contributor to GitHub. Last year, about 1,300 Microsoft employees actively pushed code to 825 top repositories on GitHub, compared to Google with 900 Google employees that contributed to about 1,100 repositories, and 134 Amazon employees that pushed code to 158 top projects.
In addition, Microsoft now depends on GitHub for all its open source activity, since it shut down its CodePlex open source code sharing site last year and selected Git as the version control system for Windows development. Under a “One Engineering System” companywide policy, the Visual Studio Team Services (VSTS) team chose Git over other version control systems––including its own internal Source Depot. They also developed the open source Git Virtual File System (GVFS), which enables users to manage massive Git repositories. Microsoft and GitHub later ported GVFS to both macOS and Linux.
GitHub complements Microsoft’s DevOps story
Microsoft recently integrated Visual Studio App Center and GitHub, to help GitHub developers automate DevOps processes as they build mobile apps for iOS, Android, Windows, and macOS devices. Visual Studio App Center enables mobile developers to build, test and distribute mobile apps to a variety of different devices, including iOS and Android, monitor the performance of those apps, and collect analytics and crash dumps to iteratively improve their apps. Additionally, integration with Microsoft’s Azure DevOps Project lets GitHub developers configure a DevOps pipeline and connect it to the cloud with no prior knowledge. And GitHub Checks API, now in public beta, enables users to perform continuous integration, linting and code analysis.
Nevertheless, questions remain about a Microsoft GitHub marriage, such as what Microsoft will do with VSTS and GitHub Enterprise.
At $7.5 billion, it’s a good deal
Although the $7.5 billion price tag seems huge, Microsoft stands to gain significant value from GitHub, the largest code host in the world.
GitHub’s customer base of around 27 million developers is a ready-made ecosystem for Microsoft to tap for support, and also a big revenue opportunity to host all those open source apps on Azure.
Chris Wanstrath, co-founder and former CEO of GitHub, joins Microsoft as a technical fellow, while Nat Friedman, former CEO of Xamarin which Microsoft acquired in 2016, takes over as CEO of GitHub.
It further establishes Microsoft as a steward for developers
Microsoft founders Bill Gates and Paul Allen built the company with developers in mind, and the company has worked closely with its developer community to establish a platform and strengthen the platform’s ecosystem. Now, as the company opens up to open source, it must expand its horizons.
Staunch open sourcers and some Microsoft haters have fled GitHub or are contemplating it. I get it. Nobody wants a big, scary vendor to manage their code and tools. But I believe Microsoft will leave GitHub alone and keep it open. Putting Nat Friedman, an open source veteran, in charge is a positive move. I compare this to my beer geek friends who refuse to drink the beer of any craft brewer that sold out to AB InBev, Budweiser’s parent and largest brewer in the world. I know there are underlying issues to their refusal. But all I can say is, Goose Island sold out to AB InBev and I still love me some Bourbon County Brand Stout.
VS Code and TypeScript are wildly popular
VS Code is developed in the public on GitHub and has had over 17,000 developer contributions, and companies such as Google use both VS Code and TypeScript to build software for their platforms. Technologies such as .NET Core, NuGet, Power Shell and Azure SDKs are other projects that Microsoft has developed in the open and hosted on GitHub.
Salesforce recently joined the Linux Foundation’s Continuous Delivery Foundation to help grow the CI/CD ecosystem. This move seems to have gone unnoticed by many, but two things stood out to me about it.
I wasn’t aware that Salesforce had its own DevOps tool, Salesforce DX, which enables developers to collaboratively build and continuously deliver apps. You’d expect that a successful, born-on-the-cloud CRM vendor the size of Salesforce has its own DevOps tooling; I’d just never heard about it.
Mostly, I know Salesforce because the company’s popular CRM platform dominates the market with as much as 27% of the CRM pie. Salesforce also has a cache of popular developer tools for building web, cloud and mobile apps with which I’m familiar. Also, co-founder Marc Benioff has an outsized persona and deep ties to the San Francisco Bay area.
The other thing that stood out is that when I think of open-source contributors, I typically don’t think about Salesforce. The company recently moved its Lightning Web Components to open source, but the Lightning UI failed to catch on among many of Salesforce’s ISV partners because of performance issues and inadequate features, especially extensibility to other CRM, e-commerce and ERP apps, said Albert Pang, president of Apps Run The World in Dublin, Calif.
Yet now Salesforce joins a group whose main focus is on open-source technology.
The CD Foundation now hosts some of the most-used CI/CD tools around, including Jenkins, JenkinsX, Spinnaker and Tekton. Salesforce itself adopts continuous delivery practices and tools, and now the company will work with the CD Foundation to work on specs for CI/CD pipelines and workflows, said Mark Interrante, senior vice president of engineering at Salesforce. Moreover, Salesforce joins CloudBees, IBM, Google, CapitalOne, CircleCI, JFrog, Huawei and Netflix as a premier member of the foundation. Meanwhile, Salesforce is also a member of the Linux Foundation, the Cloud Native Computing Foundation, Hyperledger, the Internet Security Research Group/Let’s Encrypt and the OpenAPI initiative.
I felt like I was missing something by not knowing about the company’s DevOps capabilities or the depth of Salesforce’s contributions to open source. But feedback from analysts who cover the industry wasn’t all that different than mine.
“I think that it’s great to see that they are making an additional step around open source like this,” said Thomas Murphy, an analyst at Gartner. “They have had open source support in the past and especially where they are positioned as a platform for development as opposed to the Salesforce CRM SaaS.”
Salesforce is not a big player in this arena, but they are making steps here because of the strength of the developer market and their desire to have a viable platform with market longevity, such as Heroku and Cloud Foundry, Murphy said. This will be key for Salesforce to maintain a strong position in the Python space and build services that users connect to. Salesforce already supports Jenkins and Buildpacks, so this is just more publicity on the open-source front, he said.
Salesforce aims to become a major enterprise application platform. On the DevOps front, that means the company must add continuous delivery capabilities to its portfolio, just like it added universal data analytics capabilities through its recent $15 billion acquisition of Tableau, said Torsten Volk, an analyst at Enterprise Management Associates on Boulder, Colo.
“I see the $100,000 per year membership of the Linux foundation more as a starting signal telling everyone that Salesforce intends to become the hyperscale cloud for enterprise applications,” Volk said.
Another interesting point is that GitHub activity around Salesforce has doubled since January, 2019, with the Salesforce Cumulus project and the TransmorgrifAI auto ML library project leading the charge.
“Salesforce certainly has the resources and the talent to jumpstart its CI/CD and open source strategy and this is what we may be witnessing right now, Volk said. “Salesforce is going out to get its share of the public cloud pie.”
GitHub has created a way to empower and financially compensate open source developers, and it could reshape the open source software development model – for better or worse.
The version control service provider’s GitHub Sponsors service, unveiled at the company’s Satellite conference in Berlin this week, enables GitHub users to financially support open source developers that have projects hosted on GitHub. GitHub will match all contributions up to $5,000 during a developer’s first year in the program. In addition, the firm will not charge any platform fees for users supporting other developers, and the company also will cover all payment processing fees for the first 12 months of the program.
GitHub Sponsors is now in private beta with a small group of developers who spend the most time on the platform, and later this summer GitHub will open the waitlist for developers seeking sponsorship, Zuegel said.
“Open source developers build the tools for the rest of us,” said Devon Zuegel, senior product manager for open source at GitHub. “Sponsors is a new way for people to connect on our platform and to pay each other as well.”
GitHub’s attempt to pay open-source software maintainers directly through the standard GitHub workflow will increase the visibility of open source projects, but it’s not the first such effort.
Boston-based Tidelift also supports open source software makers and maintainers for the value they create. Tidelift Subscriptions provide customers with support for open source software (OSS) projects that are vetted for security and quality, and Tidelift shares subscription fees with the open source project maintainers to ensure that the software they produce meets commercial standards, said Donald Fischer, TideLift co-founder and CEO.
Paying OSS contributors: A double-edged sword?
This trend has the potential to uplift the OSS community – or polarize it.
Some believe GitHub Sponsors has the potential to do for OSS what Apple’s App Store did for mobile developers: give them a chance to create a sustainable lifestyle to work on code they love, or that is important to well-heeled enterprises. “Even if that value accrues to a small number of deserving committers, it’ll still be a net positive,” said Jeffrey Hammond, an analyst with Forrester Research.
At the same time, while many still wonder if the OSS model is sustainable, most of the focus seems to be on corporate creators of OSS projects, not individuals, he added.
Others see a slippery slope with such efforts, suggesting that they will widen the gap between the OSS haves and have-nots.
“There will be conflict between developers who accept sponsorships and those who don’t. There will be corporations buying themselves into certain key projects, and there will be developers making good money by contributing to these projects on GitHub,” said Torsten Volk, an analyst at Enterprise Management Associates. “This fundamentally changes the character and social dynamics of GitHub. To which degree, remains to be seen.”
Likewise, though he says he was skeptical of the idea at first, efforts like GitHub Sponsors could lead to more consistency in OSS projects by providing incentives for developers to stick with projects and ensure unwavering quality, said Charles King, an analyst at Pund-IT, Hayward, Calif.
“At the end of the day this is a more honest and transparent model than developing open source on an employer’s dime, where there may be a conflict between what is right and what the employer pays for,” said Holger Mueller, an analyst at Constellation Research, San Francisco.
Meanwhile, others like David Heinemeier Hansson, creator of the Ruby on Rails web development framework, roundly criticized the GitHub move, saying that it could make the process of creating open source software too transactional. “I think it’s a grave risk to the culture of open source,” Heinemeier Hanson tweeted.
Moreover, the fact that Microsoft owns GitHub is not lost on critics who fear that the software giant may strive to exert undue influence over the OSS world by becoming the standard platform for OSS developers to get paid. Developer concerns about Microsoft’s influence over GitHub and open source started as soon as word of the acquisition came out last year, and they haven’t abated.
For instance, when GitHub recently introduced the GitHub Package Registry, Mike Milinkovich, executive director of the Eclipse Foundation, said, “A monopoly on both development experience and artifact pipelines. Just what I always wanted when I imagined the future. Not,” in a tweet that has since been deleted.
Others expressed concern that efforts like GitHub Sponsors will spur developers to join popular projects that have greater sponsorship and abandon others — or to follow the money. Sure, there’s bound to be some of that, but in most cases the sponsored developers are not likely to make tons of money. The contributions will be more like tips from individuals that use an OSS project and want to say thanks.
I’m all for GitHub Sponsors and overall efforts for developers to get paid for their efforts. If there was such a thing for journalists I’d turn my sponsorship page on in a minute. My main concern would be how it might impact my agreement with my employer. And I expect that a lot of developers with “day jobs” will have similar concerns,
Although low-code software development platforms are a hot area of software development, many pro developers and enterprise development shops eschew these tools.
One myth is that low-code tools limit the kind and scale of applications developers can build. While this is true for many tools, particularly no-code tools primarily aimed at business analysts and non-programmers, some low-code platforms are powerful enough to enable developers to create complex systems. Rymer cites examples of developers who used low-code platforms for heavy lifting: one built an application that routes 1.5 million orders per day, and another developed a full ERP system for gas-field management.
I have seen evidence of this myth in my reporting, particularly when it comes to enterprise application development. Many enterprises will turn to a low-code tool to empower non-programmers to build departmental apps. This is usually a response to a shortage of professional programmers. Companies can’t afford to have their core programmers working on departmental apps, which are typically limited in scope and may be as simple as automating paper-based tasks. This is the realm of the so-called citizen developers.
Blue Apron for coding
I liken the lower-end low-code and the no-code tools for non-programmers to ingredient-and-recipe meal kit services like Blue Apron for folks who don’t know their way around the kitchen. The more they experiment and learn independently, the better they become.
In fact, I have spoken with several pro developers who started out as citizen developers using no-code systems and then went on to become professional programmers based on their experience with the lower-end platforms. They wanted to learn more and either took a class, enrolled in a boot camp or simply taught themselves to code. These folks defy any myths about low-code and have no problem using low-code tools as professional programmers.
Many professional developers use more powerful low-code tools as productivity aids to prototype and build apps much faster than they could by hand-coding. Moreover, low-code platform vendors are bolstering their tools with artificial intelligence to further extend the capabilities of the platforms.
For instance, OutSystems in Boston is adding artificial intelligence features into its products, to help developers gain even more productivity. The company also will link to AI services that are publicly available to help organizations build AI-based apps.
Rymer’s second myth of low-code systems is that they lock developers out of open source, APIs and flexibility.
Regarding flexibility, Salesforce.com recently updated its low-code platform, the Salesforce Lightning Platform, to enable users to use spreadsheets to build modern applications with clicks and not code.
“If your goal is to assemble your own platform, then low-code is not the right tool for you,” Rymer said in his post. “But low-code platforms do incorporate widely used open source components, including Spring, React, Angular, and Cloud Foundry.”
Rymer also noted that many low-code platform vendors offer different deployment options such as Docker and Kubernetes. In addition, the platforms integrate with all kinds of data sources and web services.
“The foundations of low-code platforms make them more flexible than most would expect,” Rymer said. “Not only can you deliver software more quickly, but you can also iterate at a faster pace.”
I totally agree with Rymer’s assessment. Low-code and no-code tools have carved out a nice position in the software development tools space. Investors and big IT infrastructure companies are taking notice. Traditional application platform players such as IBM, SAP and Pivotal have struck up strategic partnerships with low-code tools provider Mendix. In August, Siemens acquired Mendix for $730 million. In June, KKR and Goldman Sachs invested $360 million in OutSystems to help the company expand its business and enhance its research and development processes.
Low-code, no-code is here to stay. It’s a hot segment of the software development market because the tools help save time and increase productivity in app development.
Software release management is really not a new area of technology, but adoption of formal processes and automated tools in this area is shockingly low. Surprisingly, some IT organizations still think they can manage release management with Excel scripts. That’s just not true now.
The release of software is now part of a company’s brand promise. So if the firm’s software fails, its brand fails. If the software fails and the brand fails, there are more costs than there would have been to invest in modern software release management tools and practices.
The complexity of software systems is creating greater need for better software release management for automated ALM. IT environments are not simple, on-premise data centers. Today software often is released on multiple platforms and there are more types of software – apps, microservices, APIs – being deployed.
The more places an organization deploys applications, the more it needs application release automation, according to Theresa Lanowitz, co-founder of voke inc. “You need it to automatically keep track of everything that’s in a particular build,” she told me. This includes not only features in a new release, but any changes made in the staging environment, your test environment, and so on.
Lanowitz frequently hears DevOps pros say that their organizations are doing continuous integration, continuous deployment, continuous testing and “continuous everything.” Yet, voke’s research shows that very few organizations are really doing continuous integration. “The automation numbers are low, and you can’t really do anything continuous unless you have good automation basics in there,” she said. Not a whole lot of organizations have that. There’s still a lot of manual activity going on the software lifecycle and in software release management.
To do continuous processes, an organization has to start with architecting software systems soundly. The enterprise has to invest time and money to allow its application processes to evolve to the point where automation can be used. It takes automation to do things such as continuous integration, continuous testing, continuous deployment, and continuous release and so on.
“When people think about application release automation, they’re thinking about speed, speed, speed of deployment,” Lanowitz said. Agile development brought good things, but the main message people took from it is: “You just have to develop faster.” Because developers have to move at this quick pace all the time, the work of QA teams often has been pushed aside.
Time-to-market has been businesses’ top application development priority for over a decade, Lanowitz said. Her recent research, however, shows a shift to software quality being the primary concern. “QA has to play a dominant role in software release management today,” Lanowitz said. In particular, QA must take over requirements, because the quality of requirement elicitation is still abysmal in the enterprise.
The need for quality assurance is a critical reason for automating software release management. When companies invest in automation, QA is built into software release processes. Rather than being overrun by the need for speedy deployment, automation enables DevOps to control the software life cycle.
Developers, testers and QA professionals all like to fill the seats at software conferences. While there are ways to convince your employer to send you, sometimes travel is just not in the cards, due to a busy schedule or daunting costs.
When you skip a conference, you miss the chance to hear talks from thought leaders, learn new practices, network and even discover upcoming technological advents. Here are four comparable ways to attain the same benefits from software conferences in the comfort of your office chair.
1. Hear from thought leaders
Follow interesting conference speakers online to stay privy to new ideas — whether it’s on their blogs or social media. It can be difficult to find entities that share genuinely informative content — versus strictly promotional info — but there are definitely those who are worthwhile to follow. Seek out opportunities to engage with, ask questions or network online with these teams or individuals.
2. Tune in to conferences remotely
Nearly every software conference, summit or large-scale event streams a number of its sessions live. While there is no opportunity to chat with like-minded listeners or ask speakers follow-up questions, live streams give you the same information as conference attendees, without missed days at the office.
This approach may also allow you greater flexibility to pick and choose which sessions or speakers to tune into. However, be mindful that smaller events within a conference — including specialized sessions relevant to your particular interests — might not air online.
3. Read about these events afterward
Look for coverage that recaps and analyzes software conference sessions and news. Many of our contributors regularly attend these events and share information from several of the speakers. If you missed a conference this year, we have stories from it — including events like IBM Think, Red Hat Summit and OpenStack Summit. Furthermore, look forward to news from upcoming conferences like Cloud Expo.
4. Check back often
If you are looking for more analysis and insight written by industry professionals, our contributors have experience in a variety of software development capacities, including DevOps, software testing, APIs and microservices — to name just a few topics. From these writers you can find breaking stories, problem-solving tips, guides for beginners, video tutorials and more.
Let’s be clear: Microsoft is dead serious about DevOps and wants to help DevOps pros. With its Visual Studio Team Services (VSTS) and Azure DevOps Project offerings, the company has delivered some of the most comprehensive DevOps tooling that you can get from one vendor.
Competitors such as IBM, CA and others also provide comprehensive DevOps tooling to help enterprise shops adopt DevOps to improve productivity of their developers, build products faster and enhance the quality of the software they deliver. But Microsoft is fresh in my mind because I attended the company’s Build 2018 developer conference recently in Seattle.
Rub some DevOps on it
It’s also fresh because I got some grief when I paid homage to one of Microsoft’s emerging star speaker’s use of the slogan “rub some DevOps on it,” which has become his tagline. The guy is Donovan Brown, principal DevOps program manager at Microsoft. Some observers questioned it, even calling it trite, dismissive and possibly even condescending to DevOps pros.
Brown has emerged as one of Microsoft’s top speakers and product demonstrators. He lives and breathes DevOps, and loves to do live demos of Microsoft’s DevOps technology to show the capabilities and openness of the platform. According to one published profile of Brown, he once pulled an all-nighter to rework a demo when someone pointed out an omission. With one hour of sleep, he got back onstage to present his new demo.
As a developer of 20 years, an Agilist and a former process consultant, Brown knows that the adoption of DevOps is no small feat. He knows the cultural and technical transformations that must occur for an organization to move to DevOps.
He explained that the phrase emerged while he and a small team from Microsoft visited a customer that had trouble implementing VSTS.
“While we were working through their process and identifying all the pain points they had, I made the comment that we were going to ‘rub a little DevOps on it and make it better,'” Brown said in a blog post on the slogan. “Everyone in the room started laughing at the thought of DevOps being a pain reliever. But when you think about it, it really is.”
He used the phrase during his DevOps demo at Microsoft’s Build 2016 event and it caught on. He said that when he got offstage, Twitter “was having a field day” with the phrase so he turned it into a hashtag: #RubDevOpsOnIt. That hashtag trends every time Brown presents. Folks familiar with Microsoft’s DevOps story know and enjoy Brown’s shtick.
But obviously, not everybody.
“Honestly I’m not a huge fan of the catchphrase. It’s pithy, it’s catchy, but all it makes me think about is Silence of the Lambs: ‘It puts the DevOps on its skin or it gets the hose again,’ ” said Ted Neward, director of developer relations at SmartSheet, Bellevue, WA.
Rather than Silence of the Lambs, when I hear Brown’s catchphrase, I think of the old Chris Rock joke from his “Bigger and Blacker” HBO stand-up special, where he says when he was young his parents viewed Robitussin as a cure-all. He said if he had broken his leg, his dad would’ve said pour some ‘tussin on it! But I know that as a joke and I know Microsoft’s approach to DevOps and appeal to DevOps pros is for real.
Brown’s intent with the catchphrase is to connect with the audience as he demonstrates how to use Microsoft’s tools to set up an end-to-end DevOps pipeline, he said.
“To talk down to the audience would be putting myself down as well; I have DevOps in my title,” Brown told me. “Why would I dismiss or talk down about myself?”
Perhaps, you just had to be there, as folks often say about things that don’t translate well from an event to the telling of it.
Works for me
In any event, I get it and it works for me. In this age of rapid app development and deployment to meet increasing demand for applications to power digital transformation efforts, DevOps is a must-have, Brown says. And like rubbing an ointment on a burn or some dry rub on a rack of ribs, it’s going to make it better.
I also must admit that I like that Brown is an African-American that excels in a field where greater diversity is sorely needed. He may come in with a light-hearted catch phrase, but watching him present, even the uninitiated quickly learn that they are watching a well-prepared DevOps master at work. He puts in the work, rehearsing relentlessly.
Still, “I’d steer clear of that catch phrase, personally, simply because I think there are better ways to express the ideal of DevOps being something that you can apply in a number of scenarios and in a number of incremental ways,” Neward said.
What is DevOps really?
Meanwhile, although Microsoft customers love Brown because he’s a great speaker, the premise of DevOps itself has yet to be clearly defined, said Theresa Lanowitz, an analyst at Voke.
Brown authored Microsoft’s definition of DevOps: “The union of people, process, and products to enable continuous delivery of value to our end users.” Yet, Voke’s research indicates that there is no standard definition for DevOps. In a survey they received more than 80 unique definitions.
Moreover, if DevOps is supposed to encourage collaboration between the dev side of the house and the ops side of the house, “Microsoft never addressed the ops side,” Lanowitz argues.
Greg Gomel is an Agile consultant and a veteran of the Coast Guard Reserve. So when he and fellow Agile consultant Ravi Verma were brainstorming earlier this year about what they could do to help military veterans it wasn’t surprising their minds turned to Agile software development.
“We wanted to do something that would improve their employment opportunities,” Gomel explained. The result was Agile for Patriots, a not for profit organization based in the Dallas/Fort Worth area that gives veterans free intensive prep so they can sit for Scrum.org’s Professional Scrum Master training test.
Although the duo were inspired by coding boot camps, they decided to take a different tack. “The biggest obstacle in dealing with companies that need to hire a Scrum Master is they want multiple years of experience,” Gomel explained. “We really wanted to provide some shadowing opportunities to help veterans get more experience under their belt to overcome that obstacle.”
So they decided to offer two days of intensive Scrum Master training, followed by two one week practice sprints and ending with presentations in front of actual hiring managers. Gomel reached out to another Dallas area veteran’s opportunity group, Allies in Service, and had them actually “vet” the veterans for the Scrum Master training program. Honorably discharged veterans with some kind of IT experience in their background were approached and in the end around 55 sat through a one-day orientation. Sixteen veterans went through the professional Scrum Master training and 10 received their certificates and went on to the two one-week sprints and presentation time in front of actual hiring managers.“That really matched our initial expectations,” Gomel said. “We were really pleased.”
But he’s also realistic that those few weeks aren’t going to be enough, by themselves, to make a substantial career change. “The certificate is going to get you in the door but it’s not going to get you the job,” he said. Instead the emphasis was on looking for “shadowing” and volunteer opportunities to give veterans as much hands on experience as possible so they have a good story to tell when interviewing.
Agile for Patriots is planning to offer another session in February 2018, again in the Dallas area. “We’re going to continue to help them try to align themselves for the highest probability of success.”
When it comes to software testing automation, it seems we all still have a long way to go. A look at a new survey from Logigear looks at the state of your software automation testing framework, and all that surrounds it, and it’s easy to understand why everyone struggles.
First, just 56% said their organization had all the skills to automate, and 34% said their teams only had some of the skills. In fact that same percentage (34%) said lack of skills was the number one reason preventing them from implementing a successful software automation testing framework. Other barriers include overall cost (32%), management doesn’t understand (31%), and the high price of tools (also 31%).
Interestingly, 38% of the survey respondents rolled out a software automation testing framework that failed, but they moved past that and now have an ongoing automation program. On the other hand 25% tried, failed, tried again and still did not succeed. An impressive 19% said they were able to initiate a software automation testing framework that worked the first time.
When asked to describe automated testing efforts, the most popular answer, at 19%, was that it eliminates repetitive tasks so time can be spent doing more interesting/important exploratory testing. And at least some companies are starting to appreciate how a software automation testing framework can improve things: 14% said it was a “very effective” part of the test process.
Logigear also asked companies how they measure whether testing works. A hefty 67% said it was by time saved, followed by number of functions automated (38%) and bugs found (34%).
To improve automation efforts going forward, 53% said they needed to make them more maintainable, while 38% wanted to add new functions or tests more quickly and 35% simply wanted to run automated tests more quickly.
How do these stats compare to your own software automation testing framework? Let us know.
Scott McCarty, head of technical product marketing for containers at Red Hat, thinks we all just need to get along, and for that to happen we need to understand each other better.
With that in mind he’s pulled together a list of 10 tech terms the business side needs to understand. Perhaps you’ll want to print this out and hand it to your product manager or line of business person.
- DevOps: “At the end of the day it’s about devs and ops getting along better and having Ops architecture embedded in the dev process so that what devs put in to production already works right,” McCarty explained. It should be flexible, but it should also be sure to reward the ops people — the maintainers — as much as the developers — the creators — are rewarded.
- DevSecOps: All of the above plus security people actually working with developers and operations people. “They’re not there to say no, they are there to help the business,” McCarty said.
- BizDevOps: “This is the next logical step, bringing the business in with dev and ops and fine-tuning it all.” The bottom line: dev and ops need to be doing what the business needs so they all need to work together. And that’s BizDevOps.
- Linux containers: “These are my babies,” McCarty joked. But he’s serious about the need for business to understand the benefits of containers. “Containers make it easy to move the code and provision or update it in different places and that allows the business flexibility. But what they need to understand is it does take some investment to make it happen.”
- Microservices: “This is completely driven by the developers,” McCarty said. “This does nothing for the ops side.” Basically microservices break an app in to pieces making it easier to divide up the work and/or bring a new hire up to speed more quickly. “This is something that enables BizDevOps.”
- Automation: “This is a confusing one sometimes,” McCarty admitted. “This really enables business flexibility, like BizDevOps.” But it can be a two-edged sword. “Automation doesn’t necessarily make a project happen faster and it can throw a monkey wrench in to the works.”
- Orchestration: “Orchestration is to help ops teams in production manage their resources efficiently,” McCarty said. “It’s not about scaling headcount but scaling the business.”
- CI/CD: Continuous integration/continuous delivery builds on everything else that’s going on and brings in testing to the process, McCarty said. “Most companies are doing CI, but not many are truly doing CD. CI makes it a simple decision to put something in to production vs. waiting 10 hours, and that gives the business flexibility.”
- Agile everything: “I see business people abuse the word ‘Agile’ all the time,” McCarty complained. “Most business people aren’t Agile. Don’t call a process Agile without understanding what it really means.” In other words, if there aren’t standups, sprints and reviews, it’s probably not Agile.
- Infrastructure as Code: “This is another piece of DevOps,” McCarty said. The ability for programmers to manage data center provisioning through high level coding gives an organization a big leg up. “From the business side infrastructure as code costs a bit more in time and money to do but the benefits are massive.”