<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>devops on Joakim Verona</title>
    <link>https://www.verona.se/tags/devops/</link>
    <description>Recent content in devops on Joakim Verona</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <copyright>(c) 2016 Copyright Joakim Verona</copyright>
    <lastBuildDate>Sun, 29 Dec 2019 00:14:00 +0100</lastBuildDate><atom:link href="https://www.verona.se/tags/devops/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Load balancing of Jobtechs openshift clusters</title>
      <link>https://www.verona.se/post/jobtech-load-balancing/</link>
      <pubDate>Sun, 29 Dec 2019 00:14:00 +0100</pubDate>
      
      <guid>https://www.verona.se/post/jobtech-load-balancing/</guid>
      <description>
        
          
            Improving availability of Jobtech services with load balancing over multiple openshift clusters
In order to further improve the availability of Jobtech services we are exploring load balancing over multiple Openshift clusters.
An Openshift cluster in itself is highly available, and with the deployment we use we can loose an entire worker node and the workloads will evacuate to other worker nodes in order to regain redundancy. In normal cases this means no service interuptions will be noticeable, since workloads are usually deployed redundantly.
          
          
        
      </description>
    </item>
    
    <item>
      <title>Gradle Versus Make</title>
      <link>https://www.verona.se/post/gradle-versus-make/</link>
      <pubDate>Sat, 16 Jan 2016 00:00:00 +0100</pubDate>
      
      <guid>https://www.verona.se/post/gradle-versus-make/</guid>
      <description>
        
          
            I needed to make a rpm from various bits and pieces, some of them java, some of them native.
I thought this was a job for Gradle, rather than Maven, because there was a lot of fiddling with files back and forth. nothing complicated, but still, maven isn&#39;t really good at that sort of thing.
After some hacking, I got mad, put my Gradle prototype on a Usb stick and stomped on it and threw it out the window.
          
          
        
      </description>
    </item>
    
    <item>
      <title>The Tao of DevOps : Building things</title>
      <link>https://www.verona.se/post/tao-of-devops/</link>
      <pubDate>Fri, 08 Jan 2016 12:53:00 +0100</pubDate>
      
      <guid>https://www.verona.se/post/tao-of-devops/</guid>
      <description>
        
          
            The principles of Tao can be applied to almost anything, as evidenced by for instance Fritiof Capras &amp;quot;Tao Of Physics&amp;quot; and Benjamin Hoffs &amp;quot;The Tao of Pooh&amp;quot;.
Tao applies well to DevOps because who knows what DevOps is? It is an idiom as hard to define as quality, and indeed DevOps is closely tied to the quality of the product.
What is Tao then? One way of putting it is that things go better if one finds the natural way of doing things and do things that way.
          
          
        
      </description>
    </item>
    
    <item>
      <title>Maven versions, and why they sometimes aren&#39;t a good fit</title>
      <link>https://www.verona.se/post/maven-versions-and-why-they-sometimes-aren-t-a-good-fit/</link>
      <pubDate>Fri, 08 Jan 2016 12:04:00 +0100</pubDate>
      
      <guid>https://www.verona.se/post/maven-versions-and-why-they-sometimes-aren-t-a-good-fit/</guid>
      <description>
        
          
            Many developers complain about Maven, how it is slow, and how it complicates life instead of making it easier. These developers might not remember how life was in the ancient days before Maven.
That said, Maven still has practical shortcomings, and one is the snapshot versioning scheme, when used in Continous Delivery pipelines.
From a developer point of view, there is no problem. Snapshots are nice. Just commit and the continuous Integration server builds a new swapshot.
          
          
        
      </description>
    </item>
    
    <item>
      <title>SoapUi and DevOps</title>
      <link>https://www.verona.se/post/soapui-and-devops/</link>
      <pubDate>Fri, 08 Jan 2016 11:42:00 +0100</pubDate>
      
      <guid>https://www.verona.se/post/soapui-and-devops/</guid>
      <description>
        
          
            There is a tendency among engineers to disparage the tools of other engineers. So, developers don&#39;t like to develop tests with gui based tools for example.
Sometimes a tool is indeed not worthy an engineers attention, for example a &#39;Golf-Ware&#39; tool. These are tools that management learned about during a round of golf with a salesperson, and then force down the throats of unwilling devs and ops.
Is Soapui such a tool?
          
          
        
      </description>
    </item>
    
    <item>
      <title>continuous delivery versus devops versus configuration management</title>
      <link>https://www.verona.se/post/continuous-delivery-versus-devops-versus-configuration-management/</link>
      <pubDate>Fri, 08 Jan 2016 11:22:00 +0100</pubDate>
      
      <guid>https://www.verona.se/post/continuous-delivery-versus-devops-versus-configuration-management/</guid>
      <description>
        
          
            Having worked in the field today called DevOps since around 2003, I&#39;ve noticed that we more or less do the same thing regardless of what its currently called. When it works well anyway. This is how I see it;
Continuous Delivery emphasizes the payoff in the end, the increased business value of having good value adding releases hit prodoction quite often.
DevOps emphasizes how Continuous Delivery is to be implemented at the people level.
          
          
        
      </description>
    </item>
    
    <item>
      <title>The I hate os-packaging antipattern</title>
      <link>https://www.verona.se/post/the-i-hate-os-packaging-antipattern/</link>
      <pubDate>Fri, 08 Jan 2016 10:57:00 +0100</pubDate>
      
      <guid>https://www.verona.se/post/the-i-hate-os-packaging-antipattern/</guid>
      <description>
        
          
            In the Java enterprise world we have application servers that we deploy our applications into. An ear file is just a zip file with some metadata. its not a bad thing as such. The problematic situation occurs when we deploy our ears to our appservers. Teams start thinking that this is an unheard of problem, and invent new systems to solve this newly discovered problem. Teams might be excused since most major appservers have also invented new styles of wheels that replace basic OS functionality.
          
          
        
      </description>
    </item>
    
    <item>
      <title>The Pattern Antipattern</title>
      <link>https://www.verona.se/post/the-pattern-antipattern/</link>
      <pubDate>Sat, 01 Aug 2015 23:07:00 +0200</pubDate>
      
      <guid>https://www.verona.se/post/the-pattern-antipattern/</guid>
      <description>
        
          
            So you are coding away at your product, and its done entirely by the book. You have builders, immutable data transfer objects, a layered architecture and whatnot.
Suddenly the deadline makes a whooshing sound as it flys by, to paraphrase Douglas Adams. But you are safe, because you have a by the book aproach, and you have done nothing wrong. Doing it by the book takes time, doesn&#39;t it.
Ok, so all your patterns are blue book, gang of four, approved, but are they really apropriate for your project?
          
          
        
      </description>
    </item>
    
    <item>
      <title>Having a server rack at home</title>
      <link>https://www.verona.se/post/having-a-server-rack-at-home/</link>
      <pubDate>Fri, 31 Jul 2015 00:00:00 +0200</pubDate>
      
      <guid>https://www.verona.se/post/having-a-server-rack-at-home/</guid>
      <description>
        
          
            A couple of years ago I bought a server rack cabinet to have at home in my apartment. The idea was that the rack would help me get rid of the mess of cables and unsound open server chassis I had at the time.
I bought the rack and learned a lot about how to build server racks.
It didn&#39;t solve any of my problems though. In fact, since the rack didn&#39;t actually fit very well in the space I had available in our appartment, the mess only increased, and made it harder to service my equipment.
          
          
        
      </description>
    </item>
    
    <item>
      <title>Fusk med FPM</title>
      <link>https://www.verona.se/post/fusk-med-fpm/</link>
      <pubDate>Mon, 22 Jun 2015 15:02:00 +0200</pubDate>
      
      <guid>https://www.verona.se/post/fusk-med-fpm/</guid>
      <description>
        
          
            (This article was originally published by Datormagazin. Republished with permission)
Fusk med FPM Om du någon gång pakekterat ett program i enlighet med ett operativsystems pakethanterare, vet du att det kan vara ganska arbetsamt.
För att göra det ännu mer komplicerat finns det i Linux-världen ett antal olika varianter. Det två viktigaste är dock RPM, RPM package manager, en på klassiskt hacker-manér rekursiv akronym, samt Deb, Debians pakethanteringssystem.
Det finns många anledningar varför man vill paketera programvaror i enlighet med operativsystemets egna inbyggda mekanismer.
          
          
        
      </description>
    </item>
    
    <item>
      <title>pinning packages with yum</title>
      <link>https://www.verona.se/post/pinning-packages-with-yum/</link>
      <pubDate>Sun, 02 Feb 2014 00:41:00 +0100</pubDate>
      
      <guid>https://www.verona.se/post/pinning-packages-with-yum/</guid>
      <description>
        
          
            Upgrading Fedora is pretty safe most of the times. This one time I had issues with the openssl package having a change that wasnt compatible with x2go.
Since I use x2go all the time I wanted to pin the version of openssl to libssh-0.5.5-1.fc20.
1yum install yum-plugin-versionlock 2yum versionlock libssh And that was it! The problem was later resolved upstream, and then you use yum versionlock clear, to remove the lock.
          
          
        
      </description>
    </item>
    
  </channel>
</rss>
