CI Tools we use

gallaylgallayl RSS Feed

CI means you have to merge small changes continuously instead of working with large diffs at the end of the development cycle. If you want to be sure that your merge won’t be causing any trouble there are several tasks to do - like creating a sandbox, building and testing on multiple environments, comparing code coverage results, etc… That’s a soul grinding work for a developer - and should be automatized.


ci_tools_k2

Before you dive in

We use GitHub nowadays and we work with pull requests. These pull requests are playing a key role in the terms of CI tooling, most of the tools are working with pull request status checks. This means when you create a pull request, the tools will check if the branch is up to date, it can be built, the tests are OK, etc…

Front-end and Node.JS tools

We have several NPM packages and the goal is the same. We want to know if the changeset can be merged safely. We want to build, test and run some static code analysis. In more detail we want a sandbox environment with Node.JS and the latest available dependencies installed, we want our typescript sources and tests to be compiled to js, run our mocha/jest unit tests and process the reported coverage from nyc.

Travis

Travis is the most important CI tool we use. You will need only a github account with a repository, a working codebase and a small configuration script. It’s responsible for creating a sandboxed environment, downloading the codebase, install dependencies, build, run the tests and report the coverage. A build can contain multiple jobs, that means you can test your code in multiple environments. We’re testing our packages on Node.js 6 (LTS), 7 and 8 in a trusty environment.

Keeping things green

If I had to choose two CI tools, it would be Travis and GreenKeeper. Greenkeeper helps to avoid the dependency hell. Really. It scans the NPM repository and if a new version of one of your project dependencies is published, it will create a feature branch for that and runs the other CI tools. If the new version is covered by your version range and the checks fails, it will raise an issue, otherwise it just deletes the branch. If the new version is not covered but the tests are OK, it will create a pull request and you will be sure that the dependency won’t break your build. Just take a look at the screenshot from this morning and think about it if you had to do it manually :) ci_tools_greenkeeper

Covering code

We use Codecov to measure our code coverage rate and check it per pull request. You can monitor coverage historically, compare between branches, even browse in annotated files. It’s clean, simple, and it’s easy to use with Travis.

Codacy

Codacy is a highly customizable code analyzer tool that can analyze your source code in terms of compatibility, security, unreachable code loops and code style.

Backend - Visual Studio Team Services

VSTS is the de facto standard for automatized builds and CI/DI with .NET. It can be used for almost all of the scenarios above, and not just for .NET. At the moment we are using it mostly for automatized web deployment and sandbox environment creation.

Have feedback on this post? Let @sensenet know on Twitter.

Need help or found a bug? Contact us.