Tyk API Management Platform & API Gateway

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The project follows semver and tags vX.X.X following MAJOR/MINOR/PATCH increments as appropriate. Historical versions are kept for use in the release pipeline as well, being available as OS packaging (deb, rpm,...) via packagecloud, and docker images from docker hub via the tykio/tyk-gateway image.

Repository on GitHub, which uses git. git is distributed.

Following semver.

We use git tags to identify each release.

Release notes are provided on github releases and link our documentation pages: https://tyk.io/docs/product-stack/tyk-gateway/release-notes/version-5.4/

https://github.com/TykTechnologies/tyk/issues/new/choose

Work gets tracked with JIRA.

Issues/PRs get acknowledged by filing a JIRA issue, and modifying the issue/PR title according to our code review conventions.

Regular review of github issues by PMs and developers where a response is given.

Non-trivial build file in repository: https://github.com/TykTechnologies/tyk/blob/master/Makefile.

Non-trivial build file in repository: https://github.com/TykTechnologies/tyk/blob/master/Makefile.

You'd use go test ./... as for any go project, as long as integration tests dependencies are met (Redis service) and properly configured via env or config file.

We cover majority of code (somewhere around 75% range), and have several recent packages with 100% coverage under internal, increasing coverage over time.

If we write new code we write new tests, the tests include BE changes, UI changes and integration changes and are all tested in our CI pipelines.

CI gate rules ensure that a passing CI tests pipeline should be present for several of our automation tests suites.

We don't implement a formal policy, however we are constantly improving the area. Our test policies are informal but all enforced with several distributed teams working on testing and having at least 4 active major CI test pipelines for different aspects of the product release lifecycle, as well as a QA team testing on their own.

We use several linters, on local with golangci-lint, in CI additionally with CodeQL and Sonarcloud, as well as regularly experiment with our own in house linters or semgrep in particular. Both golangci-lint and our in house linter tools are published with a FLOSS license.

Several new in house linting rules have been added in the recent past, mostly addressing code structure changes identified as troublesome in aiding our development and testing efforts. We're adding linters and covering the changes in the future as part of our coding standards and concerns.

There are several contributors that meet this criteria accross the organisation.

In house OWASP trainings, as well as previous experience for many of the projects developers.

A lot of attention paid to authorization, authentication, hashing and FIPS compliance.

We're using the go standard library, particularly the crypto/tls package, to provide functionality in a secure way, implementing features on top.

Uses HTTPS/TLS/mTLS, certificate pinning, root CAs.

Github secrets.

golangci-lint for style and bugs, in house tools like schema-gen lint (godocs), go-fsck lint (import aliases) published as FLOSS.

We're using several scanners to test our release docker images and binaries, covering both binary vulnerabilities or environment ones.

Our release schedule is approximately 8 weeks allowing some time with regression testing and release delays. Dependencies are bumped within this timeframe, addressing reported issues. We have some exceptions for our LTS release, as we're currently forced to use a RHEL8 compatible environment. This is raising up ongoing challenges.

It's been said that CGO is not Go, however these are internal implementation details of the go standard library. While it's possible that an issue may exist there and be detected with fuzzing and fixed in the future, we rely on such issues being solved with regular upgrades and maintenance.