So for my company's deployment pipeline (which is evolving towards CI+CD), I'm being asked to deploy a Jenkins server.
As it happens, all the staging and production servers are already being deployed using SaltStack as the orchestration system.
Is it worth it to deploy Jenkins using orchestration, for reason of 'reproducible-ness', or should I just deploy it manually?
In short, probably yes - after checking with whoever asked you to do it. I'm not sure how Salt works (as I work with Puppet), but it'd be worth checking if someone online hasn't already handled a lot of the details in some pre-built module.
Other Jenkins-specific considerations regarding "reproduce-ability" include the Jenkins jobs/pipelines.
This can be handled with the JobDSL plugin and Pipelines, which were introduced with Jenkins 2.0. JobDSL can create the jobs for you based on a Groovy DSL loaded from source control such as git, while Pipelines can also be directly loaded from git.
The approach I'd take regarding builds is to create Jenkins and one "seed" jenkins job in Salt, that is really a JobDSL-type loaded from Git. The JobDSL loaded by this job can then create Pipeline-type jobs where the pipeline is a "Jenkinsfile" kept as part of a project's source code.
You also want to handle the list of Jenkins plugins and their configuration using Salt so that anything your builds may depend on is also installed. The simplest approach to provision slaves is then to use plugins to provide build tools.
Install using SaltStack as all the staging and production servers are already being deployed using it and SaltStack will shorter deployment time. One needs manual intervention for special configuration tasks.
Consider copying tested configuration to installed server to avoid manual efforts. You can stop jenkins using jenkins.exe stop, thereafter push configuration files to installation folders and start jenkins using jenkins.exe start
