Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-06T13:12:26.390Z
Answers: 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 :)
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-04-06T13:15:35.187Z
Answers: 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.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-04-06T13:18:04.907Z
Answers: 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.
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-04-06T13:20:09.573Z
Answers: i meant continuous deployment in a way that it includes some quality checks
Answers: karthikeayan
Answers: CC BY-SA 3.0
Answers: 2017-04-06T13:24:48.963Z
Answers: @DanCornilescu That means 4 CI/CD systems, one test and prod in two groups for cross validation... sounds really overkill for this use case.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-04-06T13:26:18.427Z
Answers: @Tensibai - it's up to the respective team to decide if it's worthy or not.
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-04-06T13:28:24.783Z
Answers: @DanCornilescu added this was my opinion in the answer, all in all this is a little aside of the question itself.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-04-06T11:46:58.753Z
Answers: 2017-04-06T13:29:50.117Z
Answers: 2017-04-06T13:29:50.117Z
Answers: Tensibai
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2018-01-11T13:50:11.280Z
Answers: your 3 points making sense.. we are following the priority in the reverse order...
Answers: karthikeayan
Answers: CC BY-SA 3.0
Answers: 2017-04-06T13:37:23.547Z
Answers: 2017-04-06T13:37:23.547Z
Answers: Dan Cornilescu
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-04-06T11:19:31.677Z
Comments: 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 ?
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-04-06T11:23:23.963Z
Comments: I am looking for some example, my requirement is for more than 10 tools.
Comments: karthikeayan
Comments: CC BY-SA 3.0
Comments: 2017-04-06T11:24:25.113Z
Comments: so for jenkins, it will be Linux and Ubuntu
Comments: karthikeayan
Comments: CC BY-SA 3.0
Comments: 2017-04-06T11:28:36.853Z
Comments: 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.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-04-06T11:32:25.127Z
Comments: Updated my question with some of the tools list.
Comments: karthikeayan
Tags: <jenkins><continuous-integration><continuous-delivery><continuous-deployment><upgrade>
Title: How to capture tools release to trigger upgrade?
UserDisplayName: karthikeayan
ThreadText: # 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**: @username_2 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**: @username_2 added this was my opinion in the answer, all in all this is a little aside of the question itself.  
  
  ---
  
  