Setting up a development environment and contribution workflow


Here are some notes that I’ve been collecting as my experience has grown since joining the Juju core team 2 months ago.


The first thing that I did when starting was play around with Juju as a user:

snap install --classic juju 

This gave me some exposure to Juju’s terminology and concepts. It’s also been useful also in case I need to check to something works with a “known good” version while I write code and break things.

Creating a Development Environment

My personal setup (Canonical employees work remotely from home) is fairly straightforward:

  • laptop (Dell XPS 15)
  • VS Code
  • Go 1.11
  • GNU make 4.2

I found the Juju README quite helpful to get started. Luckily, Juju builds very easily via:

$ go get -d -v
$ make dep
$ go install -v

As it happens, this can be simplified further by simply running:

$ make install

You should now have a working Juju binary at $GOPATH/bin/juju.


My general pattern for fixing bugs:

  • Branch from the develop branch of the Juju git repository
  • Make changes to the code
  • Run a few tests locally:
    • make pre-check
    • go test ./path/to/folder/...
  • Run all unit and integration tests via Canonical’s build infrastructure for Juju. This is activated by pushing to my local branch to Github, then creating a pull request.

When developing a new feature, I often need to experiment by live testing on a LXD cluster locally:

  • Bootstrap locally with LXD: juju bootstrap localhost testing
  • Deploy a minimal workload: juju deploy wiki-simple
  • Make changes to the code (often including copious logging messages!)
  • Follow the unit testing steps above
  • Run the following commands:
    • Create a new Juju binary: make install
    • Upload the new binary and upgrade the current system on the fly: juju upgrade-model --build-agent
  • Lower Juju’s logging levels: juju model-config logging-config="juju.apiserver=TRACE;juju.api=TRACE;<root>=DEBUG"
  • Evaluate the system by running juju commands with the --show-log --logging-config="<root>=TRACE" arguments, e.g. juju --show-log --logging-config="<root>=TRACE" status


Nice post, thanks for sharing and helping new folks with some of those common getting started issues. It’s easy to take such knowledge for granted if you’ve been around while.

There’s one glaring inaccuracy though - I’m sure you meant to type Goland instead of VS Code :stuck_out_tongue: