Moreover, it was found out pull request merge times, meaning the interval between a submitted code improvement and its incorporation into the project, was reduced by 7.5 hours. This shows that when developers have more work flexibility, they work longer hours and are more productive.

Following these findings, companies have started to rethink office-bound work policies.

However, there are concerns about the fact that work could take the place of personal time and rest breaks, thus, making it not a sustainable solution. The report indeed showed that there are over 56m developers building projects and it is expected to have 100m by 2025.

It was reported that JavaScript still remains the most popular programming language used and TypeScript made the most significant gains over the past year.

The report also stated that software vulnerabilities can go undetected for more than four years. Once it is known that security has been compromised, it takes about 4.4 weeks before it is fixed. Therefore, this represents an opportunity to improve vulnerability detection and response.

The post Report found that software developers’ productivity increased during lockdown appeared first on DevOps Online North America.

The application development world is continuously changing, evidenced by the analyst community’s frequent revisions of their various categories, definitions and scope of application development tools and platforms.

The state of industry flux is fuelled by organisations clamouring for a single platform and tool set that can help them quickly deliver omni-channel, customer-grade apps spanning desktop, web, mobile, wearables and chatbots.

The right low-code solution based on open standards can be invaluable in an era of ‘more apps, faster, that run anywhere’. That said, not all low-code solutions are created equal. Here are three red flags to watch for when evaluating a solution.

1. Black Boxes

Low-code gets a bad rap due to an ‘impenetrable black box’ perception, which is understandable considering developer reluctance to run mission-critical services on something over which they have no control.

The answer to increased productivity in a fast-paced environment shouldn’t be the extreme of no-code black boxes, but a low-code solution that’s an ‘open box’ – based on open standards and with a full view of the source. Low-code at its core is merely a tool whose value is derived from those who use it – and that calls for a professional developer, not a no-code business user.

Low-code for pro developers is about writing once and running across platforms, while maintaining full control over the user experience.

2. Monolithic Architectures

App development was already complex. Today’s expectations include limitless scalability across multiple channels, compounded by a rapid shift to cloud-based development using containers and microservices. Development teams need to meet those expectations while maintaining focus on the user experience.

Developers are skeptical of low-code solution architectures, viewing them as antiquated, monolithic, and unfriendly to application deployment. Some of the reasons for this are:

• Monolithic low-code architectures can be easy to develop and deploy initially, but in the long run tend to be ‘tightly coupled’, making them difficult to scale and maintain. If any program component needs to be updated, this often requires large portions of the application to be rewritten
• Monolithic low-code architectures can be difficult to understand because they frequently have dependencies that aren’t apparent because they’re baked into the solution. With many low-code solutions, you’re saddled with trying to manage the development, testing and production work for a monolith, minus the ability to develop, test, deploy and scale components individually.

3. Proprietary Toolsets

A plus of having proprietary tools bundled into a low-code solution is alignment of the tools and hopefully the platform, since they come from the same vending source. In theory, this should benefit developers and ultimately the business.

However, the realities of proprietary tools include steep learning curves, vendor lock-in and an ecosystem of code samples, tutorials and communities applicable only to that vendor – all of which could be spotty or non-existent.

In some cases, a platform vendor promotes their use of standard languages but still locks it within proprietary development process.

Besides the expense and time involved in learning and integrating niche skills, seasoned developers will likely resist transition to a vendor’s proprietary tools. It separates them from mainstream development communities and isn’t impressive on a resumé.

In addition, proprietary code can be tough to debug with fewer resources available to find examples and address issues.

With a view now focused by the inflexibility and risk, it’s clear why professional developers are reluctant to recommend proprietary tools.

What’s an ideal solution?

The ideal would be to have the cloud capabilities provided by the likes of AWS or Azure at your disposal, combined with the ease of low-code deployment.

Developing on a serverless cloud-based platform allows the platform to manage and auto-scale the microservices and functions. If you combine this with a Node.js backend and a JavaScript-based frontend for web and mobile, you have a full-stack option. The benefits are manifold:

• Combining a serverless and low-code platform built on JavaScript allows organisations to meet demand for consumer-grade omni-channel experiences using existing developer skills
• Different developers or even different teams can work on their portion of the application independently without conflicting with changes made by other teams
• Updates can be made without rewriting or redeploying the app code
• Code is reusable across apps and easier to maintain as functionality is isolated.

The result is developers are freed to focus on app capabilities and user experience, while the platform manages the rest.

The key is having a low-code platform based upon a widely-used and standardised language that has a strong ecosystem of tools, libraries and learning material. I believe that language is JavaScript.

JavaScript offers the ability to use a common language on both the front and backend of an application, and it has the added benefit of enabling frontend developers who are already familiar with its capabilities.

And for organisations moving to full stack development, they can use a full stack approach leveraging JavaScript for both front and backend development.

Mark Troester, VP of Strategy, Progress 

The post When developers shouldn’t trust low-code solutions appeared first on DevOps Online North America.

Before adopting XebiaLabs XL Deploy, KLM used an in-house automated software deployment tool, which resulted in problems and errors in over 70% of all software deployments.

Gaining faster and reliable software deployments

KLM decided that an automated application release tool would be the most beneficial way from a “self service” model, in order to gain faster and reliable software deployments. In addition, XL Deploy accelerated Java and. Net deployments in cloud and middleware environments, such as IBM, WebSphere, Oracle, WebLogic and JBoss.

“Normally, deploying an application in the target environment is a highly administrative activity. Although scripts can be used to help simplify the work, the process remains sensitive to errors, needs constant updating and requires very specific expertise,” said Ronald Bosch, who is responsible for the project team in the Web Systems department at Air France-KLM.

“With XL Deploy we were able to automate the deployment process end to end. It has made us less reliant on specialists because deployments can be performed easily by developers and system administrators.”

As a result of the new changes, Air France-KM reduced the turnaround time for major projects by several weeks, and employers focused more on the interesting aspects of their jobs, other than administrative tasks.

Edited from press release by Leah Alger

The post European airline Air France-KLM invests in DevOps appeared first on DevOps Online North America.

Agile coaches, software developers, and DevOps engineers

The new members will join Sainsbury’s 900 strong digital and technology team on a range of projects, including the company’s apps and core business systems.

According to the company, “agile coaches, software developers and software development managers in addition to DevOps engineers” will make up the new roles. The new roles will allow Sainsbury’s to expand upon its in-house digital and technology capabilities, as well as providing a stronger team to make shopping for the retailer’s 25 million customers much easier.

Jon Rudoe, Digital and Technology Director at Sainsbury’s said, “The world is changing rapidly. Our vision is for Sainsbury’s to have a world-class Digital and Technology function to ensure that we can deliver great services for our customers whenever and wherever they want to shop with us.”

He continued, “This announcement demonstrates our commitment to that goal and to attracting the best talent in this ever developing sector. As Manchester is the UK’s second largest technology hub, it’s a natural step for us to recruit here.”

The ever-growing need for tech engineers

Over the past year Sainsbury’s have more than doubled their digital and technology staff in order to compete with its competitors, such as the UK’s dominant online grocer Tesco.

Other large retailers such as Marks & Spencer and John Lewis have also set up tech hubs in order to compete, and to enable themselves to stay one step ahead of the rapid changes in online shopping, increasing the need for software developers, software development managers, agile coaches and DevOps engineers.

Mike Dilworth, Agile & DevOps Transformation at Sainsbury’s, will be a speaker at this year’s The National DevOps Conference. Attend his talk to hear more on the subject.

Written by Jordan Platt

Sources:

The Guardian

The Drum

Recruiter

Manchester Evening News

The post Sainsbury’s invests in Manchester-based DevOps roles appeared first on DevOps Online North America.