bf5f1b5f20
In order to do development on the installer itself in a sane way, we need a reasonably fast and automatic way to get a fresh environment to try to run it in. This calls for some form of virtualization. Choices include * A public cloud, like EC2 or Digital Ocean. These could work, if we wrote some suitable scripts against their APIs, to manage appropriate base images (as AMIs or snapshots respectively) and to start fresh instances/droplets from a base image. There'd be some latency on starting a new VM, and this would also require the user to have an account on the relevant cloud with API access to create images and VMs. * A local whole-machine VM system (hypervisor) like VirtualBox or VMware, perhaps managing the configuration through Vagrant. These hypervisors can be unstable and painfully slow. They're often the only way to get development work done on a Mac or Windows machine, which is why we use them there for the normal Zulip development environment; but I don't really want to find out how their instability scales when constantly spawning fresh VMs from an image. * Containers. The new hotness, the name on everyone's lips, is Docker. But Docker is not designed for virtualizing a traditional Unix server, complete with its own init system and a fleet of processes with a shared filesystem -- in other words, the platform Zulip's installer and deployment system are for. Docker brings its own quite different model of deployment, and someday we may port Zulip from the traditional Unix server to the Docker-style deployment model, but for testing our traditional-Unix-server deployment we need a (virtualized) traditional Unix server. * Containers, with LXC. LXC provides containers that function as traditional Unix servers; because of the magic of containers, the overhead is quite low, and LXC offers handy snapshotting features so that we can quickly start up a fresh environment from a base image. Running LXC does require a Linux base system. For contributors whose local development machine isn't already Linux, the same solutions are available as for our normal development environment: the base system for running LXC could be e.g. a Vagrant-managed VirtualBox VM, or a machine in a public cloud. This commit adds a first version of such a thing, using LXC to manage a base image plus a fresh container for each test run. The test containers function as VMs: once installed, all the Zulip services run normally in them and can be managed in the normal production ways. This initial version has a shortage of usage messages or docs, and likely has some sharp edges. It also requires familiarity with the basics of LXC commands in order to make good use of the resulting containers: `lxc-ls -f`, `lxc-attach`, `lxc-stop`, and `lxc-start`, in particular. |
||
|---|---|---|
| .circleci | ||
| .tx | ||
| analytics | ||
| confirmation | ||
| corporate | ||
| docs | ||
| frontend_tests | ||
| pgroonga | ||
| puppet | ||
| requirements | ||
| scripts | ||
| static | ||
| templates | ||
| tools | ||
| zerver | ||
| zilencer | ||
| zproject | ||
| .codecov.yml | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.json | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlint | ||
| .isort.cfg | ||
| .npmignore | ||
| .travis.yml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Dockerfile-dev | ||
| LICENSE | ||
| README.md | ||
| Vagrantfile | ||
| manage.py | ||
| package.json | ||
| version.py | ||
| yarn.lock | ||
README.md
Zulip overview
Zulip is a powerful, open source group chat application that combines the immediacy of real-time chat with the productivity benefits of threaded conversations. Zulip is used by open source projects, Fortune 500 companies, large standards bodies, and others who need a real-time chat system that allows users to easily process hundreds or thousands of messages a day. With over 300 contributors merging over 500 commits a month, Zulip is also the largest and fastest growing open source group chat project.
Getting started
Click on the appropriate link below. If nothing seems to apply, join us on the Zulip community server and tell us what's up!
You might be interested in:
-
Contributing code. Check out our guide for new contributors to get started. Zulip prides itself on maintaining a clean and well-tested codebase, and a stock of hundreds of beginner-friendly issues.
-
Contributing non-code. Report an issue, translate Zulip into your language, write for the Zulip blog, or give us feedback. We would love to hear from you, even if you're just trying the product out.
-
Supporting Zulip. Advocate for your organization to use Zulip, write a review in the mobile app stores, or upvote Zulip on product comparison sites.
-
Checking Zulip out. The best way to see Zulip in action is to drop by the Zulip community server. We also recommend reading Zulip for open source, Zulip for companies, or Zulip for working groups and part time communities.
-
Running a Zulip server. Setting up a server takes just a couple of minutes. Zulip runs on Ubuntu 16.04 Xenial and Ubuntu 14.04 Trusty. The installation process is documented here. Commercial support is available; see https://zulipchat.com/plans for details.
-
Using Zulip without setting up a server. https://zulipchat.com offers free and commercial hosting.
-
Applying for a Zulip internship. Zulip runs internship programs with Outreachy, Google Summer of Code, and the MIT Externship program. Zulip also participates in Google Code-In. More information is available here.
You may also be interested in reading our blog or following us on twitter. Zulip is distributed under the Apache 2.0 license.