Jira, Confluence, and GitLab

Operation Pushbutton

Setting Up Tools

After rolling out Confluence and Jira, it is important that you connect to the installed services via HTTPS immediately after the ansible-playbook call. Both initially greet you with the configuration wizard. Because this wizard only sets up the admin password, the page is open to anyone without a password. Using Confluence and Jira together, it makes sense to run the user database only in Jira and connect Confluence to Jira (Figure 5). During the initial setup, Confluence and Jira also ask for the license, which you should ideally have at hand.

Figure 5: During the initial setup, Confluence can be configured to use Jira as a source of user data.

The agile work center is almost finished: The only thing missing is GitLab. A separate playbook (gitlab.yml) rolls it out, but again you need to adjust different values up front – in particular, for the mail configuration that GitLab will use later on and in the usual entries for managing the Apache host configuration.

Finally, a last call to ansible-playbook rolls out the Omnibus edition of GitLab. GitLab also comes with its own configuration dialog, which you should close immediately after deployment.

Meaningful Approach

The presented setup with Confluence, Jira, and GitLab has several advantages. First, it's idempotent: You can thus call the individual playbooks or playbook.yml again at any time to restore the default setup. Any changes to the setup should first be implemented in Ansible and then rolled out.

The three services get along well: As mentioned before, Jira can serve as a user database for Confluence. If you want, you can connect GitLab and Jira so that GitLab commits lead to log entries in Jira issues; also, Jira tickets can be referenced directly in Confluence pages. All these features are very useful for distributed teams that want to stay agile.

Infos