Continuous Integration, Quality & Testing
- Typical Length
3-14 Days
- Locations
USA, Europe, Israel, Remote
- Standards
- Deliveries
- Modern and rich continuous quality inspection (integration) solution
- Rich metrics provided directly to the team productivity apps (e.g. Slack)
- Including local, IDE-hosted, tools for immediate feedback
More Info & Practices
Getting most of the quality tasks automated leaves more time for developers to focus on features development and ensures no preventable issues leak into the solution. A typical CI solution that I build with customers includes at least 8 metrics and quality gates – multiple type of testing, linting, vulnerabilities check, licensing check, code complexity and more. Metrics alert the developer immediately, sometime even during coding or after few seconds via Slack.
Best Practices
- At the very least, write API (component) testing
Most projects just don’t have any automated testing due to short timetables or often the ‘testing project’ run out of control and being abandoned. For that reason, prioritize and start with API testing which is the easiest to write and provide more coverage than unit testing (you may even craft API tests without code using tools like Postman. Afterward, should you have more resources and time, continue with advanced test types like unit testing, DB testing, performance testing, etc
- Detect code issues with a linter
Use a code linter to check basic quality and detect anti-patterns early. Run it before any test and add it as a pre-commit git-hook to minimize the time needed to review and correct any issue. Also check Section 3 on Code Style Practices
- Carefully choose your CI platform (Jenkins vs CircleCI vs Travis vs Rest of the world)
Your continuous integration platform (CICD) will host all the quality tools (e.g test, lint) so it should come with a vibrant ecosystem of plugins. Jenkins used to be the default for many projects as it has the biggest community along with a very powerful platform at the price of complex setup that demands a steep learning curve. Nowadays, it became much easier to set up a CI solution using SaaS tools like CircleCI and others. These tools allow crafting a flexible CI pipeline without the burden of managing the whole infrastructure. Eventually, it’s a trade-off between robustness and speed – choose your side carefully
- Constantly inspect for vulnerable dependencies
Even the most reputable dependencies such as Express have known vulnerabilities. This can get easily tamed using community and commercial tools such as 🔗 nsp that can be invoked from your CI on every build
- Tag your tests
Different tests must run on different scenarios: quick smoke, IO-less, tests should run when a developer saves or commits a file, full end-to-end tests usually run when a new pull request is submitted, etc. This can be achieved by tagging tests with keywords like #cold #api #sanity so you can grep with your testing harness and invoke the desired subset. For example, this is how you would invoke only the sanity test group with Mocha: mocha –grep ‘sanity’