Continuous integration and deployment became an important part in software development. There are multiple SaaS platforms available, but you probably want to keep ownership of your code, host and run your own continous integration and deployment tool. Strider is an open source platform doing exactly this job.

This is the first post in our series of blogposts about Strider. We’ll look into various topics around the platform. Starting at how to install and configure Strider, going to service integrations with GitHub, GitLab, Bitbucket, Gogs, Heroku, Slack and HipChat. Additionally, we have you covered with the configuration and activation of email notification for build statuses, GitHub build status reports and how to configure Strider webhooks.

Strider Series Overview

Strider is a highly extensible continuous integration and deployment server. It offers many plugins to enhance the platforms functionality. The platform itself integrates and is composed of plugins.

Integration with Services via Plugins

Strider is build around a substantial Extension Loader and integrates seamless with GitHub, GitHub Enterprise, Bitbucket, GitLab, Heroku, Slack, and many more. You can connect your GitHub and Bitbucket accounts to Strider and test your hosted repositories automatically with every commit or push. Deploy your successfully tested code to Heroku and get notified in your Slack chat afterwards.

Some plugins are available on GitHub and you can, of course, add your own. Strider plugins are NodeJS libraries and you can just install them via npm install in striders project repository or the servers admin panel. Actually, each plugin contains a strider.json metadata file or strider section in package.json to expose information about the plugin. This information tells Strider how to handle the plugin and which JavaScript files should be initialized and loaded to work correctly.

Mighty Plugins

Strider is highly customizable through plugins. They provide many features and massively extend the platform.

Plugins can

• register their own custom HTTP routes
• add hooks to execute arbitrary build actions
• extend the database schema with custom fields
• publish and subscribe to socket events
• create and modify Striders user interfaces

Strider Environments — Webapp vs. Worker

Strider separates plugins in two environments and loads them separately: webapp and worker.

Webapp Environment

The webapp is Striders UI you can visit via browser and configure the platform. Plugins expose options to manipulate via the webapp. You can define your templates, request manual configuration, serve static files, listen to global Strider events and many more.

Worker Environment

The worker code is loaded for each job running with Strider. Using the strider-simple-runner plugin your code gets tested on the same process as your webapp. Worker plugins stick to the exposed extension loader methods to plug their functionality into Strider and make it available to the platform. Worker may load plugin specific configurations from the webapp like paths to SDKs, which branches should be tested or framework versions to test against.

Supported Programming Languages

The default Strider deployment ships with support for the following programming languages

• NodeJS
• Ruby
• Python

You probably know and we just want to be clear: testing code requires you to have the programming languages installed on the machine running Strider.

You can add support for additional languages or framework by creating a new plugin. We’ll cover the topic on how to create your own Strider plugin later in this series.

What’s Next

In our next post we’ll guide you through the installation process of Strider. Further, we’ll show you how to install plugins to extend the platforms feature set.

In the next weeks, we’re going to walk through major capabilities and integrations of Strider.

---

Additional Resources

• Strider on GitHub
• Strider Extension Loader
• Strider Plugin Template to create your own plugin