Uffizzi is a productivity tool designed to improve the quality and speed of software development teams by augmenting their agile process with Continuous Previews (CP). CP is an automation-enabled best practice that encourages cross-functional teams to continuously collaborate during the development process by providing feedback on features that are still in progress. With CP, git topic branches are previewed in a production-like environment before they are merged into QA/Test. This modern approach to agile lets teams separate functionality testing from integration testing, which enables them to trace the root cause of issues more quickly. The following diagram illustrates how CP improves the standard agile development process:
Figure 1: Improved Agile Process with Continuous Previews
Uffizzi takes the hard work out of creating temporary hosting environments for Continuous Previews. It enables teams to easily deploy previews of git branches to production-like environments and share those previews with teammates. Each preview gets a shareable URL that is continuously updated when you push new commits. Unlike other preview platforms that focus only on front-ends, Uffizzi supports full-stack applications and their backing services such as databases or cloud APIs. Learn more about of Continuous Previews.
Uffizzi customers can deploy git branches and container images to their organization’s Kubernetes-based infrastructure, without requiring knowledge of Kubernetes itself or managing detailed configuration specifications. Alternatively, Uffizzi provides a managed cloud solution for teams that do not utilize Kubernetes.
In addition to the applications themselves, Uffizzi simplifies the management of entire application ecosystems—from network policies and role-based access to configuration files and connections to backing services (data storage services (databases, object storage, etc.), caches, task queues, cloud APIs, monitoring services, and other applications).
ℹ️ It is not recommended to connect Uffizzi to any production systems, such as a production database.
Uffizzi is best used as a rapid development and preview tool - environments in Uffizzi are meant to be ephemeral—i.e., they act as temporary hosting environments to test new features, and once the feature has been merged, they can be destroyed. You should think of Uffizzi as a type of QA tool, therefore application and service containers should never connect to any of your production systems.
INSTALLATION & ARCHITECTURE
If you are using a self-hosted version of Uffizzi, it installs as a single Kubernetes Pod using the kubectl command. A Uffizzi team member will provide you with a YAML file for installation. Once Uffizzi is installed on your cluster, end-users will create deployments via the Uffizzi web application.
The Uffizzi architecture consists of two primary components:
- Web application — A user interface for managing deployments and other resources
- Controller — An agent installed on the Kubernetes cluster that will host the deployments
The following diagram illustrates an installation of Uffizzi on two customer clusters:
The controller cluster agent is isolated from a customer's other Kubernetes components via a NetworkPolicy.
Applications must be containerized to be compatible with Uffizzi. Customers can deploy existing container images from registries such as Docker Hub and/or Uffizzi can build images from source code. Deployments can include a mixture of prebuilt images and source code repositories. If choosing the latter option, customers can specify the build process by including a Dockerfile in the source repository, or they can let Uffizzi attempt to build from source using our integrated support for cloud-native buildpacks. Support for multi-container (aka “microservices”) applications is included in either method.
Uffizzi is designed for full-stack applications, so it expects that at least one of your containerized services is listening for HTTP connections. For each deployment, you must specify the container that will receive incoming traffic and on what port number the service is listening. This is the same number as that specified in the EXPOSE command in a Dockerfile. All environments created and managed by Uffizzi have HTTPS enabled by default.
Deployments & Pod Model
Uffizzi deployments are distinct from the Kubernetes Deployment object. They are an abstraction of various Kubernetes concepts, including Workloads, Services, Ingresses, Network Policies, and other objects that describe what, when and how an application ecosystem should operate.
In Uffizzi, deployments consist of the following components:
- Application or service repositories
- Backing services (e.g. data storage)
- Configuration files
- Deployment settings
Your team can create new deployments manually, via saved configuration templates or by setting up event-driven automations called Continuous Previews. In addition to deploying an application’s components, Uffizzi automatically configures a load balancer, domain and certificate for each deployment, giving your developers an endpoint to test and a public URL to share with other stakeholders.
Each application or service is deployed as a container to the cluster. All containers that exist within a Uffizzi Deployment are bundled into a single Kubernetes Pod, which share a local network by default. This means that all containers in a deployment can communicate on localhost (See Networking & Load Balancing section below for more details). This model was chosen because it resembles many developer's local development environments, so there is usually no need to reconfigure your networking model for deployments on Uffizzi.
You can create multiple deployments to simultaneously test many different versions of your application, but these deployments do not share any internal network on your cluster. Separate deployments in Uffizzi can only communicate over the public Internet.
Templates are saved deployment configurations that allow you to quickly fill in a deployment specification, instead of having to manually add components each time you want to create a new deployment. When creating a new deployment, you’ll be asked whether you want to start from scratch or use a template.
Templates can be created to represent different configurations of your application ecosystem. For example, one template may instruct your application container to connect to a development database (represented as a backing service), whereas another template may have it connect to a staging database. Similarly, your development template may include environment variables or configuration files that differ from your staging template.
Working with templates helps save time, prevent configuration errors and reduces hurdles for your teammates to deploy their code.
In Uffizzi, repositories are source code or image repositories that can be added to a deployment. To add a repository to a deployment, users must first grant Uffizzi read-only access to the service that hosts the repositories. Uffizzi never writes to user repositories. Currently, Uffizzi supports integrations with GitHub and Docker Hub. Users can grant Uffizzi access to specific repositories or an entire account’s repositories. Access can be revoked at any time either by revoking access tokens or (in the case of GitHub) by uninstalling the Uffizzi GitHub App.
*Integration with Gitlab, Bitbucket, AWS' Elastic Container Registry, Azure's Container Registry, and GCP's Container registry are on our roadmap.
Backing services are instances of services that your application utilizes but which are not managed by Uffizzi. Examples of backing services include:
- data storage services (databases, object storage, etc.)
- task queues
- cloud APIs
- monitoring services
- other applications
Backing services consist of a name, tags (optional) and connection details specified as environment variables. You can create a bank of backing services that your project utilizes, and when you create a new Deployment, you can add backing services from the list to inject connection details into your application containers at runtime.
These environment variables are saved as Kubernetes ConfigMaps or Secret Resources, depending on whether the Save as Secret option is selected. When a backing service is added to a deployment, Uffizzi mounts it as a volume in the Kubernetes deployment specification. The volumes are available to the entire deployment.
Uploaded configuration files are stored within Kubernetes as ConfigMaps or Secret Resources, depending on whether the Save as Secret option is selected. Uffizzi then mounts them to your containers as volumes at the specified mount path.
ℹ️ Uffizzi passes instructions to the Kubernetes API to store the Volumes as Secrets. For self-hosted users his means that your cluster needs to be configured with a secrets management tool.
Networking & Load Balancing
Every application environment in Uffizzi includes a load balancer whose job it is to receive incoming HTTPS requests (e.g. https://foo.app.example.uffizzi.com) and route those requests to the HTTP Port you specified on one of your running application containers. Uffizzi load balancers are set up and managed automatically, so you don't need to enable or configure them. Uffizzi also handle HTTPS certificates for you; our certificate authority is trusted by all popular web browsers and devices. All of a deployment's containers share the same internal IP address, so they can talk to each other at
localhost. Each container should listen on different ports.
Separate deployments do not share an internal network, so they may only communicate over the public Internet.
Role-based Access Control
Accounts are the top of the Role-based Access Control (RBAC) hierarchy and are associated with a customer billing account, typically the customer's company or organization. Support for one user login to have access to multiple organizational accounts is not currently support but is coming soon. A user can be a member of multiple accounts by using different email logins.
Projects fall within accounts and represent a development effort such as an application ecosystem (repositories, backing services, configuration files, etc.). Projects can be created and edited by Admins and Developers.
Members are individual users that are associated with an Account and have an assigned access role of Admin, Developer, or View Only. The Member who creates an Account is by default the Admin of that account. An account must always have one Admin.
Single Sign On (SSO)
If an Organization has enabled SSO for their account, then a member must utilize the SSO function to log in to their account. Administrators are still able to login in via email/password to administer SSO configuration.
A. Admin - Admins can do all and see all within an Account. Admins can view and edit every project and deployment. This is the highest level of permission for an account. Uniquely they control the RBAC and billing, installation, and clusters as required. An Account must have at least one Admin. Admins control who is on the Account.
B. Developer - Developers can view and edit projects and deployments that they either created or were invited to. They can NOT edit billing, installations, and clusters. A Developer can create Projects and be invited to Projects. A Developer can invite other Developers to a Project. A Developer can only “see” and “edit” Projects that they either created or were invited to.
C. View Only - View Only members can only view project that they have been invited to. They cannot make any edits.
The following is a list of features that are currently not supported, but which are on the Uffizzi product roadmap.
Create a Preview from Docker Compose
Upload your Docker Compose file or pull it from a Github registry and Uffizzi will read Compose and create a Preview based on its specifications.
You will soon be able to share your deployment Preview URLs to your JIRA Kanban board.
Docker Volumes & Persistent Volume Claims
Uffizzi does not currently support Docker Volumes. While your application may write to local storage, it is not guaranteed to persist. This is because Uffizzi does not support the Kubernetes concept of persistent volume claims (PVC). Support for PVC and Docker Volumes is included in our product roadmap.
Other Image Registries
Uffizzi will soon include support for image registries that implement the open-source Docker Registry HTTP API V2 protocol.
Other Hosted Git Soutions
Uffizzi plans to add support for importing source code from GitLab and BitBucket.
Multiple Public Ports
Uffizzi will in the future add the ability to expose multiple public ports for a single container, but this is currently not supported.
Currently a customer email address can only be associated with one organizational account. Support for a user login to be a member of multiple organizations is coming soon.
OTHER UNSUPPORTED FEATURES
UDP, (S)FTP and Other Protocols
Uffizzi does not support these or other non-HTTP protocols.