Questions about the product and use cases
At its core, Pact is a managed version of the Open Source Pact Broker, with added features for teams and enterprises looking to scale their contract testing.
Pactflow allows teams to increase their application quality and time-to-market by speeding up the release cycle for large-scale integrated systems. Whether you build microservices, messaging systems or cloud native (e.g. lambdas) systems, Developers and Testers can write simple, isolated unit tests for each integration in their application and generate API contracts that are guaranteed to be up-to-date with their code, ensuring all dependencies are always compatible.
This unit test approach is simpler, faster and more reliable than traditional end-to-end acceptance tests for a variety of use cases, and can be integrated easily into a holistic testing strategy.
Pactflow is designed for developers, QA teams and engineering managers who are building, testing and supporting distributed systems - such as web applications based on a microservices architecture.
Modern product engineering typically involves numerous, often distributed teams, requiring an effective collaborative workflow to evolve the design of their APIs.
Pactflow addresses this challenge, by enabling a seamless workflow to share contracts between teams, visualise their dependencies and integrate their CI, whilst reducing the administrative burden of managing extra servers for tooling.
Yes - see above!
Yes - see above!
Pact and Spring Cloud Contracts are API contract-testing tools that produces contracts. Pactflow manages the lifecycle of these contracts, and provides a workflow to manage them in your continuous delivery pipelines.
Yes, we a fully backwards compatible with the Open Source Pact Broker. We contribute regularly to the Open Source roadmap, and generally release multiple updates a week to our customers.
If you need help migrating from a self-hosted broker, please contact us at email@example.com
Questions around pricing plans
If you need to migrate data, just drop us a note at firstname.lastname@example.org and we'll take it from there.
No. All credit card activity and information is handled by our third-party provider, Stripe. See Stripe’s Terms and Services.
The Team plans use a "seat" based model, where you purchase capacity for how many Users you need and assign them as required.
A user is considered any person or system that requires independent access to the system. For example, if you have two team members Sally and Billy that will be logging into the UI, as well as a separate dedicated CI user for automation, they will each consume one seat for a total of 3.
Each user gets a read-only and read-write API token that can be used for automation (e.g. for use in CI or local verification testing). Each user is able to rotate these tokens as needed.
Yes. All users contribute to the same system, they are simply separately authenticated.
Users may login with their GitHub credentials (via OAuth2) or standard login (user/pass)
For CLI automation, any user may also create API tokens for use by standard Pact Tooling
Yes you can. If you'd like to retain your historical data, contact us at email@example.com and we'll help you through the process.
Questions around security and data protection
We take security seriously. In addition to 3rd party penetration testing, we perform regular security scanning of our platform, encrypt all data at rest and use TLS for all remote communication. Each customer is further isolated via separate database instances.
Yes, you can manage your own Pact Broker, however you will be responsible for its operation, including security, maintenance and upgrades. Pactflow is a fully-managed, highly-available, and hardened deployment of the open source version with an improved user experience.
While we don't currently provide an option to host the commercial product on-premise, contact us if you'd like to discuss this further.
Yes, the following are our registered IP addresses which can be used to lock down access into your platforms:
Yes there are a number of strategies we employ, which can be briefly summarised as follows:
We don't share the data with any third party, anonymised or otherwise. To provide our service, we of course need to analyse the contents of pact files and other interactions with our service to be able to provide the features. All data is encrypted at rest, and no customer has access to other customers' data.
Please read our terms and conditions for further clarification on our non-disclosure policy.
At the moment, webhook secrets are stored in our database in clear-text (as per the OSS version), however we do follow a number of standard security protocols for the hosted environment (see above).
We currently suggest that any tokens in the broker are appropriately scoped in nature, and cycled as per standard security best practices. We have it on our roadmap to address this, however we can’t provide a timeline for this feature at this time.
For user (and system user) access, as it stands, there is just one mechanism: two principles - a read-only and read-write user authenticated via Basic Authentication. We are currently working on implementing social login via GitHub and other providers, as well as SAML authentication in the future. We expect to have this feature production ready early in 2019. If you would like to be involved in an early beta program, or have feedback for our roadmap we would love to hear it.
In terms of network access, the only deployment topology supported is HTTP+TLS access over the public internet.