Testing, CI, and feature branches

acchou2

I'd like to understand the best practice around using FusionAuth in a typical development process. For example:

I have multiple feature branches and want to test them independently.
I have a production system
I have a CI system that automatically runs builds and tests, and each time it should start with a well defined infrastructure state for testing.
I use an IaC tool like CloudFormation, Terraform, or Pulumi and I'd like to manage infrastructure in a versioned way.

Are there any suggestions for how to work with FusionAuth in way that fits in with these practices?

dan

Hiya @acchou2 ,

Welcome to the FusionAuth community!

You have a couple of options for setting up CI/CD and managing FusionAuth via IaC tools.

Kickstart is perfect for CI/CD as it gives you full access to the FusionAuth API to configure your test instance however you want. However, it works only on fresh installs; it doesn't execute if it sees anything that indicates the instance has previously been configured. (There is an open issue to allow Kickstart migrations, feel free to upvote it.)
There is a community supported terraform provider. However, this does not cover the entire FusionAuth API, though it covers many use cases. If you'd like to voice your support for an official, complete Terraform provider, please upvote this issue.
You can use the migration system of your application, or an external migration system. For example, if your application is on rails, you could write rails migrations that use the ruby client library to set up and modify your FusionAuth instance. The same kind of migrations exist for many different web application frameworks, and could be used independently of your application if desired.
You can write shell scripts/python/etc using the client libraries whenever you have changes. See the client libraries page for supported languages.

So while I don't know your entire situation, in general I'd suggest using kickstart for the CI/CD system (view the docs for how to use kickstart with docker), and one of the other three solutions for ongoing IaC modifications to your system. If you didn't want two different configuration systems, skip Kickstart.

Hope that helps.

dan

Here's an example of a rails migration which modifies application configuration:

require 'fusionauth/fusionauth_client'

class ModifyApplicationToUseForm < ActiveRecord::Migration[6.1]
  def up
    client = FusionAuth::FusionAuthClient.new(ENV['FA_API_KEY'], Rails.configuration.x.oauth.idp_url)
    request = { 
       "application": {
                "registrationConfiguration": {
			"enabled": true,
			"type": "basic"
		}
	}
    }

    res = client.patch_application(Rails.configuration.x.oauth.client_id, request)
    if res.status != 200
      raise "did not succeed."
    end
  end
  def down
 client = FusionAuth::FusionAuthClient.new(ENV['FA_API_KEY'], Rails.configuration.x.oauth.idp_url)
    request = { 
       "application": {
                "registrationConfiguration": {
			"enabled": false
		}
	}
    }

    res = client.patch_application(Rails.configuration.x.oauth.client_id, request)
    if res.status != 200
      raise "did not succeed."
    end
  end
end

Worth noting that I pull the API key from the environment and the location of the FusionAuth instance and the application id from a config file. Often you'll need to do a lookup if you are modifying other entities.

You'd run this via the normal migration process: rails db:migrate to roll forward and rails db:rollback to rollback.

You can also run more than one operation in a single migration, but there's no transaction surrounding these changes, so if you are making three changes and step number 2 fails, you'll have to back out step number manually.