Antidot Engineering practices
Software quality and robustness largely depend on the development methods in place. We can proudly say that Antidot applies state-of-the-art practices, with a constant effort to sharpen our methodology.
We apply state of the art techniques and good practices when coding. Our software is built using the continuous delivery paradigm.
- Code is versioned in an internal Git source control system: all changes are logged and monitored
- Our products are built using the latest versions of C++ , Java and Python (currently C++14, Java 8 and Python 3.5). We apply security patches and bug fixes to the third libraries that we use. Software is built using the continuous delivery paradigm
- For every feature or bug fix, a topic branch is created. Jira epic/stories/tasks are created to track the development and our SCM tools (Gitlab CI and Jenkins) are linked to Jira.
- A bug fix commit is not accepted without a test proving the issue is really fixed.
- Code is written in pair mode and/or a merge request is created for review.
- Code includes unit tests, functional tests and large tests involving all components.
- These tests are run for every commit (several thousand tests).
- Branches can be merged into a release branch only after review and if CI status is still ok.
- Every commit on a release branch that leaves CI green (including large tests) creates an installation candidate. It usually takes about an hour for a valid commit to produce an installation candidate.
- Each night additional tests that recreate a full day of production are run on the latest installation candidate, including stress and recovery tests.
- Every week (or more often if required) we cherry pick the « best » candidate of the week (usually the latest) and deliver it to our customers (release note + updated package repository).
- Code coverage and static analysis tools are frequently run (Sonar,CppCheck, SafeHTML …).
- Penetration tools are frequently run.
- DevOps feedback loop provides quick feedback to developers about installation, upgrade or production issues.
- Our Ops team can (and will) refuse to install a version if they are not confident with its quality.
- Our Ops team uses state of the art monitoring and automated deployment tools (Puppet, Ansible, FAI …). Our servers are regularly cleaned and reinstalled automatically.
- Container technologies (LXD, Docker) are heavily used to isolate environments and to ensure that our software can be built, installed and run from a bare OS installation.
- When preparing rollout of major update, DevOps transversal teams perform non-regression, performance and stress tests of the new binaries (“you build it, you run it”).
- A/B techniques are used to progressively roll out new versions in our Cloud. Changes and user behavior are monitored in real time and can remove a new version from production if required without having the need to rollback software or databases.
- Feature toggles enable progressive rollout of new features to selected customers.
- HipChat rooms are used internally for efficient communication between Dev, Ops, internal Professional Services users, …
- Teams work in Agile mode, using Scrum, Kanban or in-house mix of various Agile methods.
- All teams use the same rhythm: iterations of 3 weeks, at the end of which retrospectives and review ceremonies are held.
- Our managers and developers frequently attend Agile Tour meetings to challenge and update their skills.
- Our developers are passionate, they attend several conferences per year (DockerCon, Fosdem, Devoxx …) and go to local meetups and JUGs.
- Every week a developer talks in front of his peers of a specific technological topic (30 minutes).
- Hackathons are held to foster innovation.
- Frequent meetings are held between stakeholders (Product owner, Support and Professional Services managers, Pre-sales staff, Top management ….) to ensure that everybody is focused on providing value to our Customers.
- Professional Services teams lead a review meeting after completion of customer’s projects. This review provides feedback to developers and ops, allow fine tuning of the backlogs. This also allow Support staff members to gain project knowledge.