<p>From your list of tools:</p>

<p>Jenkins and Github have apt/yum repositories you can use to install and upgrade. </p>

<p>For Atlassian products, best up to date information about repositories I can found is <a href="https://confluence.atlassian.com/display/DEV/ShipIt+8+-+Debian+Package+for+JIRA" rel="nofollow noreferrer">This ShipIt experiment</a> and it seems unlikely to change from <a href="https://community.atlassian.com/t5/Bitbucket-questions/Is-it-possible-to-install-Bitbucket-with-apt-get/qaq-p/300619" rel="nofollow noreferrer">this forum post</a><br>
The workaround may be <a href="https://community.atlassian.com/t5/JIRA-questions/I-would-like-to-track-Atlassian-product-releases/qaq-p/308308" rel="nofollow noreferrer">parsing the mailing list</a> to update the deploy. </p>

<p>Now if you really want something automated to handle the installation and configuration of your tools, you can try a Configuration Management System like Chef/Puppet/Ansible/Salt.</p>

<p>For Chef I know better, there's cookbooks for Jira and Confluence maintained.<br>
For the rest you'll be on your own writing the bits to deploy and configure.</p>

<p>This means having 4 CI/CD systems (at least), two 'groups' validating each other, as a pipeline won't be able to validate and upgrade itself properly (inception). That sounds overkill in my opinion.</p>

<p>At the end of the day, there's no silver bullet for all and every software you may use, each will have its own particularity and way to be installed and you'll have to workaround those bits.</p>

CC BY-SA 3.0
2017-04-06T13:12:26.390Z
As long as you have a proper QA validation pipeline for the upgrade - I don't see what's the difference between deploying some piece of sw vs another :)
Dan Cornilescu
CC BY-SA 3.0
2017-04-06T13:15:35.187Z
Because here you're upgrading your pipeline infrastructure... It will have a hard time validating itself. (inception ?) And in the context of the question I understand the quote as 'install updates as soon as available directly into prod' which is not a good idea IMHO.
Tensibai
CC BY-SA 3.0
2017-04-06T13:18:04.907Z
It might not be trivial, but not impossible. But it is not the _same_ pipeline - it's a different system being upgraded, with its own pipeline.
Dan Cornilescu
CC BY-SA 3.0
2017-04-06T13:20:09.573Z
i meant continuous deployment in a way that it includes some quality checks
karthikeayan
CC BY-SA 3.0
2017-04-06T13:24:48.963Z
@DanCornilescu That means 4 CI/CD systems, one test and prod in two groups for cross validation... sounds really overkill for this use case.
Tensibai
CC BY-SA 3.0
2017-04-06T13:26:18.427Z
@Tensibai - it's up to the respective team to decide if it's worthy or not.
Dan Cornilescu
CC BY-SA 3.0
2017-04-06T13:28:24.783Z
@DanCornilescu added this was my opinion in the answer, all in all this is a little aside of the question itself.
Tensibai
CC BY-SA 3.0
2017-04-06T11:46:58.753Z
2017-04-06T13:29:50.117Z
2017-04-06T13:29:50.117Z
Tensibai
<p>For tools which don't offer access to a source code management repository that you can automatically query for updates you could start with a manual trigger, then take a closer look for how is that trigger activated by humans and maybe automate the task:</p>

<ul>
<li><p>there could be upgrade email notifications sent to a subscriber list. An automatic email processing entity could be subscribed to get these messages and distil them into an automatic trigger</p></li>
<li><p>the tool itself may performs such checks, maybe displaying messages in its log(s). In such case an automated tool could be parsing the log and derive an automatic trigger from it. If the upgrade availability is displayed in a GUI it's may be more difficult, but not impossible, to automate that as well</p></li>
<li><p>the tool provider may (or could be persuaded to) offer a programmatic way to query for or be notified about upgrades - API, webhook, service, etc</p></li>
</ul>

<p>I'd suggest keeping the human monitoring and ability to activate those triggers in parallel with the automated system - just in case there are unexpected changes rendering the automatic triggers ineffective. Such monitoring could be more relaxed (say once a week/month), just as a precautionary safety net.</p>

CC BY-SA 3.0
2018-01-11T13:50:11.280Z
your 3 points making sense.. we are following the priority in the reverse order...
karthikeayan
CC BY-SA 3.0
2017-04-06T13:37:23.547Z
2017-04-06T13:37:23.547Z
Dan Cornilescu
<p>We capture our applications release by using commits from source code management, new package into the artifactory system etc.,</p>

<p>How can we capture my tools release from vendor so that I will trigger my upgrade script to upgrade my tools itself, for ex: upgrading Jenkins whenever new release available from Jenkins itself?</p>

<p>List of tools am expecting to upgrade:</p>

<pre><code>1. Jenkins
2. GitHub Enterprise
3. Atlassian Jira
4. Atlassian Bamboo
5. Atlassian BitBucket Server
</code></pre>

<p>Basically, continuous deployment(with proper pipeline including testing) to production without human interaction for these tools.</p>

<p>Note: I am looking for some example, my requirement is for more than 10 tools. So for Jenkins, it will be Linux and Ubuntu.</p>

CC BY-SA 3.0
2017-04-06T11:19:31.677Z
That's quite broad, I don't think there's an universal manner, that depends on which tools and which platform it is running on. Even for your jenkins example, on linux or windows ? which distribution/flavor ?
Tensibai
CC BY-SA 3.0
2017-04-06T11:23:23.963Z
I am looking for some example, my requirement is for more than 10 tools.
karthikeayan
CC BY-SA 3.0
2017-04-06T11:24:25.113Z
so for jenkins, it will be Linux and Ubuntu
karthikeayan
CC BY-SA 3.0
2017-04-06T11:28:36.853Z
For [jenkins on ubuntu](https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu) and [jenkins on redhat](https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Red+Hat+distributions). Best idea is to use vendor repositories (when they exists) for linux boxes. But out of the air example valid for 10 different tools doesn't exist. this makes this question really too broad as is. would be better if you can refine it, at least listing the tools as such an answer can address them all or not.
Tensibai
CC BY-SA 3.0
2017-04-06T11:32:25.127Z
Updated my question with some of the tools list.
karthikeayan
<jenkins><continuous-integration><continuous-delivery><continuous-deployment><upgrade>
How to capture tools release to trigger upgrade?
karthikeayan
# How to capture tools release to trigger upgrade?

(Asked by: username_0 on 2017-04-06)

We capture our applications release by using commits from source code management, new package into the artifactory system etc.,
How can we capture my tools release from vendor so that I will trigger my upgrade script to upgrade my tools itself, for ex: upgrading Jenkins whenever new release available from Jenkins itself?
List of tools am expecting to upgrade:
1. Jenkins
2. GitHub Enterprise
3. Atlassian Jira
4. Atlassian Bamboo
5. Atlassian BitBucket Server

Basically, continuous deployment(with proper pipeline including testing) to production without human interaction for these tools.
Note: I am looking for some example, my requirement is for more than 10 tools. So for Jenkins, it will be Linux and Ubuntu.

**Tags:** jenkins, continuous-integration, continuous-delivery, continuous-deployment, upgrade

> **Comments:**
> **username_1**: That's quite broad, I don't think there's an universal manner, that depends on which tools and which platform it is running on. Even for your jenkins example, on linux or windows ? which distribution/flavor ?  
> **username_0**: I am looking for some example, my requirement is for more than 10 tools.  
> **username_0**: so for jenkins, it will be Linux and Ubuntu  
> **username_1**: For [jenkins on ubuntu](https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu) and [jenkins on redhat](https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Red+Hat+distributions). Best idea is to use vendor repositories (when they exists) for linux boxes. But out of the air example valid for 10 different tools doesn't exist. this makes this question really too broad as is. would be better if you can refine it, at least listing the tools as such an answer can address them all or not.  
> **username_0**: Updated my question with some of the tools list.  

---

## 2 answers

### Answer by username_2 on 2017-04-06. Score: 3 | Accepted answer

For tools which don't offer access to a source code management repository that you can automatically query for updates you could start with a manual trigger, then take a closer look for how is that trigger activated by humans and maybe automate the task:

* there could be upgrade email notifications sent to a subscriber list. An automatic email processing entity could be subscribed to get these messages and distil them into an automatic trigger
* the tool itself may performs such checks, maybe displaying messages in its log(s). In such case an automated tool could be parsing the log and derive an automatic trigger from it. If the upgrade availability is displayed in a GUI it's may be more difficult, but not impossible, to automate that as well
* the tool provider may (or could be persuaded to) offer a programmatic way to query for or be notified about upgrades - API, webhook, service, etc

I'd suggest keeping the human monitoring and ability to activate those triggers in parallel with the automated system - just in case there are unexpected changes rendering the automatic triggers ineffective. Such monitoring could be more relaxed (say once a week/month), just as a precautionary safety net.

> **Comments:**
> **username_0**: your 3 points making sense.. we are following the priority in the reverse order...  

---

### Answer by username_1 on 2017-04-06. Score: 3

From your list of tools:

Jenkins and Github have apt/yum repositories you can use to install and upgrade.

For Atlassian products, best up to date information about repositories I can found is [This ShipIt experiment](https://confluence.atlassian.com/display/DEV/ShipIt+8+-+Debian+Package+for+JIRA) and it seems unlikely to change from [this forum post](https://community.atlassian.com/t5/Bitbucket-questions/Is-it-possible-to-install-Bitbucket-with-apt-get/qaq-p/300619)  
The workaround may be [parsing the mailing list](https://community.atlassian.com/t5/JIRA-questions/I-would-like-to-track-Atlassian-product-releases/qaq-p/308308) to update the deploy.

Now if you really want something automated to handle the installation and configuration of your tools, you can try a Configuration Management System like Chef/Puppet/Ansible/Salt.

For Chef I know better, there's cookbooks for Jira and Confluence maintained.  
For the rest you'll be on your own writing the bits to deploy and configure.

This means having 4 CI/CD systems (at least), two 'groups' validating each other, as a pipeline won't be able to validate and upgrade itself properly (inception). That sounds overkill in my opinion.

At the end of the day, there's no silver bullet for all and every software you may use, each will have its own particularity and way to be installed and you'll have to workaround those bits.

> **Comments:**
> **username_2**: As long as you have a proper QA validation pipeline for the upgrade - I don't see what's the difference between deploying some piece of sw vs another :)  
> **username_1**: Because here you're upgrading your pipeline infrastructure... It will have a hard time validating itself. (inception ?) And in the context of the question I understand the quote as 'install updates as soon as available directly into prod' which is not a good idea IMHO.  
> **username_2**: It might not be trivial, but not impossible. But it is not the _same_ pipeline - it's a different system being upgraded, with its own pipeline.  
> **username_0**: i meant continuous deployment in a way that it includes some quality checks  
> **username_1**: @DanCornilescu That means 4 CI/CD systems, one test and prod in two groups for cross validation... sounds really overkill for this use case.  
> **username_2**: @username_1 - it's up to the respective team to decide if it's worthy or not.  
> **username_1**: @DanCornilescu added this was my opinion in the answer, all in all this is a little aside of the question itself.  

---

