It was Sunday 09:45, the birds were cheerping and the sky was blue, when suddenly this peace was interrupted by the ring of my phone. That’s right, I was on stand-by duty that week and my consumer just called to inform me that the production environment of Citrix is down.

After some question I determined there, indeed, is something wrong so I started my laptop, logged on to the environment and started troubleshooting. Hmmm, no icons on Storefront? That must be the database.

Once headed to the database server, which is on Server Core, I fired the command Get-Service -Name MSSQLSERVER which showed me the service was not running. That’s weird, because the start-up type of the service was on Automatic. I started the service and the issue seemed to be solved. I realized the servers were automatically patched on Sunday, could this be related to a reboot?

I decided to perform a system info to determine the boot time of the server, and this confirmed the server has suffered from a reboot.

So, to prevent this from happening again I need something to make sure SQL is getting started when it’s down, so I can enjoy my well-deserved sleep
I went ahead and started programming some PowerShell after which I converted my script to an executable. The script works with the input of a JSON file, which is easy to read. This JSON file needs to be installed in “$env:ProgramFiles\TimTools\ServiceWatcher\ServiceWatcher.json” / “%programfiles%\TimTools\ServiceWatcher\ServiceWatcher.json. You are free to choose where you will place the executable file, but the most logical place to me is to store it in the same folder:

Once satisfied with the location you can than install the service with the following command:

.\ServiceWatcher.exe -install
Start-Service ServiceWatcher

Of course, you can also uninstall the service with ease:
.\ServiceWatcher.exe -uninstall

Or when you lost the executable:
sc.exe delete ServiceWatcher

Let’s put it to the test, in the example below we’re testing with Citrix components, but of course you can specify each service you like and you can even use wildcards like in the example below:

The application has only been tested on Windows 10 21H1 and Windows Server 2019 but should theoretically also work on Windows 7, Windows 8/8.1, Server 2008, Server 2012 and Server 2016. However, I do not recommend the use of deprecated operating systems. More information about Windows lifecycles can be found on https://docs.microsoft.com/en-us/lifecycle/products/

So, after implementation I think it’s fair to say I nailed it and now I can go back to sleep.

If you’ve encountered a bug/question/feature request, feel free to contact me on LinkedIn.

The application can be found on GitHub.

Author: Tim Nissen

Leestijd : 3 minuten

Veel organisaties zijn actief bezig met de transitie naar een DevOps strategie. Hoewel DevOps een veel gebruikte methode is binnen de softwareontwikkeling is het wellicht een nieuwe aanpak voor andere afdelingen zoals bijvoorbeeld de wekplek beheer binnen een organisatie. Zo lopen veel organisaties tegen verschillende uitdagingen bij de adoptie van de DevOps strategie binnen deze afdelingen. In deze blog post voorzien we je van 5 tips voor een betere adoptie van een DevOps strategie.

Voor diegene die nog niet bekend zijn met DevOps, DevOps is een set van middelen voor het combineren van software development (Dev) en IT-operations (Ops). Het is bedoeld voor het inkorten van de development lifecycle en intoduceert ook nieuwe manieren van werken zoals bijvoorbeeld continous delivery. Meer informatie over DevOps is hier te vinden.

1. Think big but start small

Desondanks de werkplek relatief simpel in gebruik is, komen er veel verschillende componenten bij kijken. In combinatie met het formaat van de organisatie moet je met verschillende zaken en afhankelijkheden rekening houden. Het is met die reden cruciaal om een hoog-over doel te hebben wat te bereiken met de DevOps strategie binnen de afdeling. Gezien de hoge mate van verandering van de verschillende componenten, is het daarom zeer belangrijk om de wendbaarheid (agility) zo veel mogelijk te verhogen.

Voor een werkplek strategie zal de focus liggen bij het automatiseren van de gehele infrastructuur. Hierdoor is het mogelijk om de gehele omgeving opnieuw op te bouwen zonder enige interactie van een medewerker. Dit zal het ultieme doel zijn waardoor de afdeling zich kan richten op het verhelpen van eventuele problemen en het iteratief toevoegen van nieuwe functionaliteiten.

Het is niet realistisch om het einddoel in een keer te realiseren. Helemaal binnen een werkplek omgeving zijn er verschillende componenten vereist voor de werking. Het is cruciaal om klein te beginnen om zo iteratief het einddoel te bereiken. Hierdoor zal het team kleine mijlpalen behalen en bekender worden met de verschillende (nieuwe) technieken binnen DevOps.

2. Alles in code

Voor sommigen zal dit misschien afschrikken maar ‘code’ is de core van een goede DevOps strategie. Met behulp van code is het mogelijk om alles te automatiseren binnen de werkplek omgeving. Alle DevOps oplossingen bevatten Git of een vergelijkbaar versiebeheersysteem. Door het gebruik van een versiebeheersysteem, zoals Git, zijn alle wijzigingen binnen de code inzichtelijk en traceerbaar. Voor het correct gebruik van Git is het advies om de juiste informatie op het internet te zoeken, zoals de volgende instructie video.

Learn Git In 15 Minutes – YouTube

Ervaring leert dat de learning curve best hoog is voor mensen die nooit gebruik hebbengemaakt van Git, en met die reden is de juiste begeleiding cruciaal.

Binnen veel DevOps oplossing wordt er ook gebruik gemaakt van Markdown. Markdown is een markup taal voor het formatteren van tekst. Het is vergelijkbaar met HTML, maar dan vele malen minder complex en is hierdoor gemakkelijk en snel op te pakken. Hierdoor is het mogelijk om ook direct documentatie op te nemen binnen de Git repository. Documentatie is door vele gezien als vervelend of niet noodzakelijk. Het is daarom belangrijk om allen relevante informatie op te nemen. Ervaring leert dat een detail level ontwerp vrijwel nooit meer gebruikt wordt en gezien de tijd en energie zonde is van de tijd. Met behulp van Markdown Architectural Decision Record, kan de structuur opgenomen worden voor het bijhouden van architecturale keuzes, wat het belangrijkste onderdeel is van documentatie.

3. Git strategie

Zoals in de vorige tip benoemd gaat het allemaal om de code. Code wordt opgeslagenin een versiebeheersysteem zoals Git. Git is dan ook de meest voorkomende oplossing binnen veel DevOps oplossingen. Desondanks dit nu specifiek om Git gaat, is dit van toepassing voor elke type versiebeheersysteem.

Binnen Git is het belangrijk om een goede strategie te benoemen betreft het gebruik van Git. Denk dan de structuur van je code repository maar ook hoe om te gaan met branches. Een branch is een aftakking dan wel een kopie van de code. Het is gebruikelijk binnen een werkplek omgeving om DTAP omgeving te hebben. Met behulp van branches is het mogelijk om een branch te hebben voor development, test, acceptatie en productie. Nieuwe functionaliteiten dan wel deployment zullen ontwikkelt worden in de development omgeving. Zodra de functionaliteit succesvol is deployed dan wel getest kan door middel van een merge of nog beter een pull request de code doorgezet worden naar test. Na het testen in de testomgeving gaat de code door naar acceptatie en als laatst naar productie.

De term pull request zal vaak binnen DevOps voorbijkomen, dit is een methode om wijzigingen binnen zowel de code als documentatie te reviewen. Helemaal in de tijd van remote werken is het een zeer prettige manier om de interactie aan te gaan over de inhoud. Met die reden is het advies om pull requests mee te nemen in de implementatie van de DevOps oplossing.

Er zijn verschillende uitgewerkte strategien beschikbaar op het internet en het advies is ook om goed in te lezen en een te adopteren binnen de omgeving. Een veel gebruikte strategie is GitFlow en is altijd een goed startpunt.

4. Pipelines

Mocht je in aanraking zijn gekomen met DevOps dan zal vast de term pipeline bekent voorkomen. Binnen alle DevOps oplossingen zit een pipeline of vergelijkbare mechanisme verwerkt om een stappenplan te doorlopen. In het stappenplan is het dus mogelijk om allerlei acties uit te voeren zoals het bouwen van een applicatie of in het geval van een werkplek omgeving, een machine uit te rollen en te configureren. De pipeline is dus de gehele motor om alle geautomatiseerd uit te rollen.

Bij het gebruik van een pipeline zijn een aantal principes belangrijk om rekening mee te houden. Maak de logica van de automation op een generieke manier zodat het bruikbaar is binnen de verschillende omgeving in de DTAP straat. Binnen de pipeline is het mogelijk om gebruik te maken van verschillende variabelen, onder andere de huidige branch. Met deze methode is het mogelijk om één pipeline te gebruiken voor alle deployments. Let hierbij wel op hoe de pipeline daadwerkelijk is opgeslagen binnen de omgeving. Binnen Azure DevOps zal een YAML gebaseerde pipeline in de Git repository worden opgeslagen. Hierdoor kan de branching strategie worden gebruikt om wijziging in de pipeline door te voeren. Indien de oplossing dit niet kan, is het verstandig om onderscheid te maken tussen de verschillende omgevingen.

5. Continous delivery

Binnen een traditioneel werkplek bouwtraject kan het soms maanden duren totdat een werkplek daadwerkelijk is opgeleverd. Dit is dan ookwel bekend als een waterval aanpak. Het bouwen gaat per component en zodra het staat is de taak van de beheerder om regulier beheer op uit te voeren. Onderdeel van de DevOps mindset is continuous delivery. Zoals eerder benoemt moet het op elk moment van de dag mogelijk zijn om de volledige omgeving op te bouwen zonder enige interactie van een persoon. Zo zou het in theorie mogelijk zijn om elke nacht de volledige omgeving opnieuw klaar te zetten zodat alles identiek en compliant is. Dit is geheel in lijn met een “immutable infrattrucutre” of “infrastrucure as code” strategie.  Wellicht gaat dat net iets te ver als startpunt, maar het is een goed steven als einddoel. Met de mindset om op elk moment te kunnen deployment creëer je de mogelijkheid om continue kleine onderdelen te releasen. Zo creëer je de wendbaarheid (agility) om snel te voldoen aan eventuele nieuwe wensen en eisen van de klant.

Conclusie

DevOps is niet alleen een toolset maar ook een mindset welke moet gaan leven binnen de organisatie voordat er daadwerkelijk waarde behaald kan worden met DevOps. Bovenstaande tips zijn een aantal aandachtspunten om rekening mee te houden bij het implementeren van DevOps binnen een werkplek omgeving. Geduld en begrip voor het leren van iets nieuws is daarbij zeer belangrijk, gezien de materie voor sommige nieuw en complex kan zijn.

Het is daarom belangrijk om ook goed te kijken naar de toolset binnen de organisatie. Het mag nooit zo zijn dat tools en andere middelen een beperking zijn bij het uitvoeren van je werk, helemaal als die het DevOps werk tegenhouden. Indien de toolset een beperking is, zal de adoptie alleen maar lastiger worden.

Afhankelijk van de werkmethodes binnen de organisatie kan het verstandig zijn om een Agile framework als SCRUM of Kanban te adopteren. Een belangrijk onderdeel van zo’n framework zijn de reviews. Dit is een ceremonie om aan verschillende stakeholder te laten zien wat de afgelopen iteratie is opgeleverd. Afhankelijk van het formaat van de organisatie is dit ook een mooi moment inzicht te krijgen wat andere afdelingen aan het doen zijn. Naast de review is de retrospective een belangrijk onderdeel om niet alleen het process, maar ook de mensen continue te verbeteren in hun werk.

Wil je meer weten over het gebruik van DevOps of eventueel hulp nodig? Vind hier meer informatie wat we vanuit RawWorks kunnen betekenen.