Project

General

Profile

Continuous Delivery and Testing » History » Version 9

Version 8 (Luke Murphey, 03/04/2017 07:41 PM) → Version 9/11 (Luke Murphey, 03/04/2017 07:55 PM)

h1. Continuous Delivery and Testing

You can use a continuous integration tool to automate testing and deploying your Splunk apps. This will allow you to:

# Test your app on several platforms and versions of Splunk automatically (or with a click of a button)
# Easily build clean and consistent copies of your app (avoids the possible corrupt builds made on Developer hosts)
# Deploy the app to your test and production hosts with a single click

Some notes:
To use a created package (spl or tar.gz), make sure to:

* Make a fetch artifact step
* Set the fetch as a file, not a directory (https://groups.google.com/forum/#!searchin/go-cd/gocd$20fetch$20zip$20artifact$20%7Csort:relevance/go-cd/Ja5lBT6bpRA/A0ojaSRqBwAJ)

Need to create a minimal account for installing apps with the following capabilities per (https://answers.splunk.com/answers/67843/capability-to-install-app.html):
* rest_apps_management
* admin_all_objects
* restart_splunkd (to restart Splunk)

You might need to add the user "go" to the "splunk" group:

<pre>
sudo usermod -G splunk go
</pre>

Should this be done using:
# The build script?
## Pros: Could hide password using secure variable; can be done in a single line; password can be globally in environment variables
## Cons: requires the build script as a material; requires ant on all agents
# Direct commands?
# Straight copying?

Using the build script:
Pros:
# Could hide password using secure variable
# Can be done in a single line
# Password can be globally in environment variables
# Could bump Splunk too

Cons:
# Requires downloading the build script as a material
# Requires ant on the agents