3

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.

  • 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 Apr 6 '17 at 11:19
  • I am looking for some example, my requirement is for more than 10 tools. – karthikeayan Apr 6 '17 at 11:23
  • so for jenkins, it will be Linux and Ubuntu – karthikeayan Apr 6 '17 at 11:24
  • For jenkins on ubuntu and jenkins on redhat. 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 Apr 6 '17 at 11:28
  • Updated my question with some of the tools list. – karthikeayan Apr 6 '17 at 11:32
3

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.

  • your 3 points making sense.. we are following the priority in the reverse order... – karthikeayan Jan 11 '18 at 13:50
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 and it seems unlikely to change from this forum post
The workaround may be parsing the mailing list 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.

  • 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 Apr 6 '17 at 13:12
  • 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 Apr 6 '17 at 13:15
  • 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 Apr 6 '17 at 13:18
  • i meant continuous deployment in a way that it includes some quality checks – karthikeayan Apr 6 '17 at 13:20
  • @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 Apr 6 '17 at 13:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.