How DevOps culture made happy campers of both our employees and clients

What is DevOps culture? Why have we adopted it? And how do both employees and customers reap the benefits from this agile-like methodology? Factry’s DevOps Engineer explains how our team leverages DevOps for delivering better software at a speedy pace. “Even when you’re new to the company, picking up on our workflow is easy as poking a string through a hole.”

Wait, what is DevOps?

DevOps is a set of principles and practices used by our team to build, test and deploy industrial software more reliably and at a faster pace. Put simply, it means that the code that is pushed by our developers, is automatically checked whether it applies to certain quality standards and styling rules, and is tested in a repeatable pipeline.

DevOps objectives:

• Speed up time to market
• A more efficient workflow
• Better team collaboration
• Enable rapid delivery
• Improve quality of code
• Higher scalability of projects

What a DevOps engineer does all day

As a young developer, I wanted to explore different things and not focus on a single SaaS product, day in and out. It’s one of the nice things about working at Factry. You’re not just committed to just one project or client. Instead, you get to handle a lot of client-specific projects in various industries, from the steel industry over to the fabrics industry.

As the company’s DevOps engineer, it is my duty to set up the initial project structures, guide the DevOps workflow and add input on new projects and concepts. I am also the one who wanders through other people’s coding all day, delivering them a second pair of eyes, and ultimately reviews the code for logic and consistency.

What is DevOps culture like?

Recent industry research illustrates once again that implementing the DevOps culture in your company workflow, leads to more effective teams and has been shown to increase productivity, reduce mistakes, and even improve job satisfaction. But what is the secret sauce of DevOps?

DevOps teams love reducing waste and eliminating bottlenecks. They see it as their mission to make team member’s lives easier through continuous improvement and automation, and to improve the client’s experience through rapid delivery and iterations. That is also why they prefer working in small teams, apply agile best practices and take collective responsibility for the entire software product.

Before and after DevOps

Before integrating DevOps culture and practices, our development process was pretty solid. However, it lacked a touch of automation. Whenever several people had worked together on older projects, I could easily tell which person had written which lines of code. Or I could even notice a different way of working, coding or setting up projects. Having to align all different styles and methods in the review process, consumed a lot of time.

The transformation

• Firstly, we started using a linting tool. Through automated code analysis, we can now maintain a consistent coding pattern, pick up first bugs and spot common bad practices as we write the code.

• Secondly, an automated structure is now in place to test the code in the pipeline before it is reviewed by someone else, reducing the amount of issues to solve with over 60%.

• Thirdly, we have built a single framework for setting up new projects, which means that basic initial steps no longer need to be reconsidered each time. Even when you’re new to the company, picking up on our workflow is easy as poking a string through a hole.

Factry’s DevOps lifecycle

Plenty of great online articles have already been written about the general ins and outs of the DevOps lifecycle stages. That is why I will only briefly map them out in the context of our own industrial software development process. Next, we will zoom in on how deployment of industrial software is different from most other software products. Hint: it’s security-related.

But first, here’s the Factry DevOps lifecycle in practice

1. Plan

A new project is broken down into smaller tasks first, which are then executed in sprints. Both the testing workflow and pipeline are set up automatically. Once the CI-workflow is added, we‘re good to go.

2. Code

Developers start writing code locally. The style and consistency of the code is validated as they write it, ensuring a uniform coding pattern. This makes it easy for colleagues to catch up on any later point in time.

3. Build

Planning and coding are the only two things that happen locally. Next, we build the project in the CI and use the linting tool again, as a security check to make sure everything is set up and used correctly.

4. Test

The testing phase runs through an automated structure. Again, linting is performed. For frontend code we use the Cypress tool to simulate user actions, such as clicking a button or filling in a text box. For backend code, we follow the more default approach of testing each function, service, controller and database query individually.

5. Release

In the release step, we add a version number to our software, and package it, so it can be deployed. Since we have a lot of modular software that is imported by other bits, releasing also entails publishing our libraries and modules that we use to our package repositories.

New software features can be delivered to clients on a daily basis, bug fixes can be executed in a matter of hours. All following the same repeatable automated pipeline.

6. Deploy

For reasons of continuity or (perceived) security, most clients store their data in an on-premise network. As data is not pushed directly to the client, deployment is trickier compared to cloud practices. We’ll get back on this.

7. Operate

After deployment, the new code is now live. If needed, changes are made to the environment in case extra services or software are needed. The client is notified and can checkout the new features. If they notice any problems further down the line, they can se our support tool Zammad in order to notify us.

This ties in closely with the monitoring step, which gives us plenty of information to make sure that the system operates correctly and smoothly after a new deployment.

8. Monitor

Log and error data of infrastructure, systems, and applications are logged in InfluxDB and visualised in the Grafana interface. This allows us to set monitoring alerts through Slack, email or texts. We can also see if there was a spike in errors (e.g. after deployment or after a certain action on the production floor) or drill down on specific errors, e.g. within a certain time frame.

The perks of on-premise deployment

When compared to SaaS-products or websites, deployment of industrial software in the DevOps lifecycle is somehow different. Mainly because most of our clients store their data in a local network instead of using a cloud-based service. Automatic deployment is therefore not an option. However, we try to follow the same steps and adapt it a little to our CI.

In the live testing environment, the client’s teams can browse the software as if it is running locally. This is a huge advantage for them, as they can test the software, follow up on the development process and have iterations applied very quickly. And for us developers, it’s nice to see changes immediately applied and get some instant gratification.

Once the client is fully satisfied with the result, we use Ansible to deploy the software. Each deployment process follows the same steps and is fully scripted, leveraging only one configuration file. Another advantage is that whenever a new version is put live, it is easy to compare new and old versions.

Moral of the story

In my opinion, adopting a DevOps culture can be useful to any development company, big or small, and save them loads of of time.

Firstly, developers don’t have to worry anymore about making releases, deploying, etc.

Secondly, you can potentially find a lot of bugs before the code goes into production, saving you time on fixing bugs later on in development.

And finally, it is a repeatable and predictable process. Once you have a standardised approach set up, everyone in the team knows what to do and expect.

So, why not get started yourself?

Share your thoughts and comments on this blog post through pieterjan.lambrecht@factry.io. Interested in working together? Contact our sales team and get a free demo of our software. Looking for a job in industrial software development? Contact our HR department.