DEV Community: Javi

Azure DevOps CODEOWNERS

Javi — Sun, 13 Aug 2023 18:19:44 +0000

So the other day I came across GitHub's CODEOWNERS feature and I really liked it. I searched for the same in Azure DevOps but couldn't find something remotely close to it. Then my entrepreneur spirit waked up and I decided to make it myself :)

But first, what is "CODEOWNERS"?

CodeOwners Feature

Some facts:

When working on a multiservice monorepo, it's very common to have different programmers working on the same repo on different features.
The programmer who wrote the feature is probably the one that knows best about it.
Some other programmer will probably "touch" that code sometime in the future (bugfix for example).
You want the Pull Request to be as professional and as short as possible.

Thus, CodeOwners came to live.

CODEOWNERS is a simple idea, each feature/service in the monorepo has an owner. A developer who "owns" that feature, knows it the best and can be held responsible, in a positive way, of that feature.
The CODEOWNERS feature in GitHub is just an easy way of enforcing that the owner will become a reviewer, automatically.

In GitHub

To make use of this feature you just need to create a file named "CODEOWNERS" in the root of the repository and add, as they show in the example, the owners of the services.
From now on every pull request that is opened will be automatically assigned to the owners.
As the CODEOWNERS file is also gitted, changes to it will also be PR'd.

In Azure DevOps

There's branch protection in Azure DevOps but it's not as powerful as CodeOwners.
I've created a simple Docker Container that adds this feature to your Azure DevOps project and works the same way.
It can also notify the owner via RocketChat :)

You can see the code here and download the image from the Docker Hub

Hope you like it!
I'm open for more ideas to add and make Azure DevOps better!

A whole post about logging? Hell Yeah

Javi — Fri, 27 Aug 2021 09:24:03 +0000

Introduction

When I started programming, logging was obviously not in my top 10 priorities. It wasn’t even on the list. In fact, I didn’t know what logging was. All I knew was to cout or Console.WriteLine, and it was enough.

Then I began to work. I understood very rapidly that logs are important. What you write, when you write it and how easy it is to understand from them is crucial for the success of a software.

One of the first tasks I had was to take care of a legacy system. This system wrote logs to the Windows Event Viewer. Never heard of that, but I quickly managed to get familiar with it. Windows Event Viewer (eventvwr.msc) is a nice GUI that comes with any Windows distribution that lets you see all your system’s logs. It is very easy to write to it and to read the logs from it.

The logs were (and, sadly, still are) awful. Warning level used to debug (I assume the reason was because the yellow color is easier to recognize and filter). Names of the developers in the logs. No real information on steps, file names, data and such. Exception stack traces from the developer’s computer (with the developer’s path), and more. You get the deal.

But the worst wasn’t any of that, the worst was the typos.

It came to a point where I started a table with the typos in the logs. You may think I’m a snob, but there were typos everywhere. So what? Big deal! No, it is bad, it made my work a lot more difficult. In order to debug an error, I would go to the source code and lookup for the error. But because of the typos, I never found the text on the first search. I had to make the same typos to find it. For example, small typos were of the type “exeption” instead of “exception”, but there were bigger ones when you really had to read it twice or more to understand the word hiding there.

Lately, I started thinking about things that surround the code. Meaning, not the code and logic of the system, but how it will run, what monitors it, how we’ll deploy it and more. For example, we’ve always written systems that run on Windows Services, now we are writing Containers (more about that here and here). Soon enough I got to think about the system’s logs. Remembering my difficult times I swore to never make something like that and to bequeath that kind of thinking to my peers. I want to take logging to the place they deserve. I want to be proud of my system’s logs.

Let’s start with a simple question.

Why do you need logs anyway?

Logs are good for investigating. If you write a piece of software for homework, then you don’t need to investigate it. Bugs or such are not important nor interesting once the homework was handed in. You can still have logs and it is always a good idea, but they aren’t required.

Logs start to become important, ney, necessary, once the software you write is for more than homework. This situation enforces you to have the ability to correctly investigate what is happening in your system. If an error occurred, you must have the possibility to understand why it happened, be able to restore it and, eventually, fix it.

Logs describe what is happening behind the scenes. It should be enough for a technician to solve problems only by looking at the logs without looking at the code. Logs can alert on issues happening in real-time, they can trigger automations and more.

We now understand that logs are important, we can move on to how to write them.

Let’s start by the log’s levels. Log’s levels are important to understand and correctly use them. Incorrectly used log levels will lead to two kinds of logs: An empty log or a messy log.

If you don’t write anything on the lower levels, you’ll need to be on the higher levels all the time just to see something, this will make your log an empty log for everyday usage.

If you write lots of logs on the lower levels, you’ll have too much information on the log. This will require you to use a lot of memory and disk for processing and storage, leading to the need to delete logs or pay a lot.

You want to find that sweet spot in the middle. It’s not a thin line, but it can be easily missed.

The levels

Different logs’ framework might call their levels different, but these are the common ones:

Trace/Verbose – “So much information” – The lowest level. This level should be able to describe almost line by line what is happening behind the scenes. Parameters values, function calls and such. Exceptions show a full stack trace. This is the technician’s level.

Debug – “Many informations” – This is sometimes mistakenly seen as the lowest level, although there are frameworks that this is actually the lowest level. This level should contain almost the same information as Verbose level with a bit less information and description on inner parameters and calls. If this is the lowest level on your framework, use it as Trace/Verbose above. In the end, it should help you Debug.
Information – “This is what’s happening” – I call this: The Default level. This should contain contour-like information of the process. What is happening, who is interacting with whom and such. This level should be enough to understand what is happening behind the scenes without giving too much information.
Warning – “This flow isn’t entirely ok, but I know how to handle this”. These logs should warn that something bad is happening but it is a handled flow. This can be an expectation failure, input validation failed, a directory missing that we’ll be created and such.
Error – “This flow isn’t ok. I still can handle this, but it will be defaulted and you may not continue with your desired flow”. The best way to think about these logs is in catch blocks, but not only. An error has occurred, the system will not function as it should, but it will continue working. Maybe the current request will fail but upcoming requests might work correctly.

Fatal – “We are doomed”. This means the system will most probably crush. An unhandled exception happened. We don’t know how to recover from this. Manual interference is mostly required.

Frameworks

In the past (up until a few months ago) I thought that libraries that let you distribute your logs to different destinations are the best and a must-have.

For example, the log4net library (log4j for dotnet) lets you write in an xml configuration file, where do you want your logs destined to. It can be a rolling file (a file that gets rolled by date or size), it can be to the console (stdout, stderr) and more.

Log4Net is the first framework I used and it has a special place in my heart. A few years ago, I had to add a feature to an existing system. This system was written many years ago and the logging was custom-made. After adding the feature I was asked for, I asked permission to change all the custom-made logging framework to log4net. This small change allowed later to better the loggings by a lot.

Every language has at least one framework (not to say tens of frameworks) for logging and they all do their thing pretty well.

In .Net Core, logging has even a default dependency injection implemented that you can use (ILogger).

Three months ago (-ish) we deployed our first system entirely based on Docker to a staging environment. We’ve been experimenting a lot with Docker but have never deployed such a system.

I was familiar with the docker logs command, that showed the stdout/stderr of the container, but I haven’t stopped to think about what was happening there. One day I saw the 12Factor article about logging, it said to only write logs to stdout/stderr and let your environment collect those logs for you. This is when I connected the dots. If Docker was able to show me those logs, it probably could write them somewhere. And I was right. Docker collects your logs (stdout/stderr) and writes them into inner log files. Suddenly, all the power of the frameworks to let you decide where you want your logs is dismissed by just writing the logs to the console and letting another system deal with them. Moreover, having to set up the logging destination of each microservice in their configuration instead of just using docker’s logging, was a real drawback.

Why is this important? First, this allows you to use the same logging mechanism on any environment (Dev, Test, Staging, Production and more). You just need your environment prepared to handle them. We move the logging responsibility from the developer of the microservice, to the environment handler.

Secondly, no more configuration files telling the logger where to write the logs to. No more empty commits that only change the configuration file. No more deciding on different formats and then changing them.

What do we do now?

I’ve set up a BELK environment for the logs.

I have a FileBeat container listening for Docker’s log files (it even has a “Container” input type!). FileBeat knows how to talk to the docker daemon to receive information on that container (image name, version, host name and such).

This FileBeat talks to a Logstash container that distributes the logs to the many systems we need to talk to. One of them is a Kafka system from which another Logstash receives the streams and inserts them into an ElasticSearch database and this is all visually from Kibana.

Wow. So much buzz words!

This same method can be cloned almost without any change to any environment or even system.

What do the developers need to do?

Just write their logs. Write away boys! Write logs without caring for anything!

We write the logs in a JSON format to be able to manipulate them easily in Logstash. But other than that, the developer just has to write whatever he wants, he will be able to see it in the console while developing and nothing has to be changed in order to make it production-ready.

Writing logs in JSON format? Why not just plain text?
Let’s say you have a method that needs to read from a file using a session Id.

You could write a log that looks like this:

“Successfully read file [{fileName}] for session [{sessionId}]”
This would look good to the naked eye, but it is not very useful for automations, statistics and graphs. Let’s say I wanted to get a list of all the files I read. I would have to make a regex that extracts that info from the text. It is possible, but it will only get harder and harder.

Instead, you could write a log that looks like this:

“{ “message”: “Success reading file”, “file”: fileName, “session”: sessionId } “

This doesn’t look so bad to the naked eye, and it is machine ready for indexing, creating statistics and such.

I’ve even seen examples where each log type has a unique ID. For our system this is currently an overhead.

We’ve made a nice infrastructure to ease the writing of the logs (of course, how could we live without an infrastructure). We made a list of the most common values we wrote to the log and made them ‘keys’ for our Json logs. This infrastructure is consumed via a small nuget package containing a lot of helper functions.

The best part? They still don’t care where the logs go. They just need to see them on the console and everything else will be taken care of.

What have I learned?

Logging is not as easy as it seems, it can be easier than you think and it is crucially important. You need to think about how it will work from the beginning of the system design. It is crucial to it to be as simple as possibly for the developers and for the sysops. It must be flexible for changes and destinations. For example, using Logstash really helped us when another client suddenly appeared and asked to receive some logs from our system too.

It’s very important to review the logs written; is the level correctly used? For the love of G’d, use a spellchecker, they are free! Have a PR made only for the logs. All of these will help you down the road.

Remember, logs live forever.

My Introduction to Docker

Javi — Fri, 23 Jul 2021 10:00:58 +0000

My Introduction to Docker

My team has decided to transition from Windows Services to Docker Containers. We’ll move to Linux and make all our new systems containerized. Very futuristic!

I was in charge of checking the Docker world from scratch and figuring out how easy it would be to make the transition.

To make this POC I decided to make the new system I was in charge of directly on Docker. This would be my POC system. I learned a lot from working this way, and as of today, the system is production ready.

I can say this whole POC was a success and now I want the whole team to be Docker-ready.

But what does that mean? I decided to make this list of must-know features to make yourself, what I call, a Docker Developer. These include the ability to build your own image, to debug it – inside and out and more. All written from a developer’s eye.

This can be seen as a Cheat Sheet on Docker commands, but it is intended to be more than that. Most cheat sheets are just an ensemble of all the common commands with a short description of what they do. I will attempt to make a more complete cheat sheet, explaining what the command does and when and why you will need it.

Let’s make sure we are talking the same language

Docker

“Docker is a set of platform as a Service (PaaS) products that use OS-level virtualization to deliver software in packages called containers” – Wikipedia.

What does this mean? Docker allows creating a software enclosed package that will run on top of your host device OS (kernel). This is lighter than running a whole VM on top of your OS and it’s more straight-forward than installing the software directly on your OS. Moreover, since it works on top of your OS and not directly on it, the same package can be used on Windows, Linux and MacOS. Say bye-bye to “it works on my machine”!

Image

A closed software package. The images are built in a layer formation where the first layer is always the basic “OS” kernel. You can choose if you want the kernel to be Linux based or Windows bases. If you use Windows based, you will be able to run only on Windows.

Every image consists of a name, a version and a signature. The default version is “latest” and that version image will be used if you don’t specify a specific version.

Container

The container is an image in running state. It can actually be running or it can be stopped. Changes you make to the container are not saved the next time the container is started from scratch.

The need-to-know commands

“docker images” (or “docker image ls”)

The first command I used. This is used to see all the images you have loaded or pulled. Your local registry. If you have just installed docker, you’ll see an empty list.

“docker pull”

Used to pull images from a Docker Registry. You most probably won’t use this command directly but when creating an image using a Dockerfile (with the “FROM” command).

“docker build .”

Tells docker to use the current directory’s Dockerfile to create a new image. You can add “-t :” to tag the images with a name and a version.

“docker ps”

Much like the Linux “ps” command, this command shows the current running containers. This is useful to know the names of the containers that are running and for how long they are running.

“docker logs ”

Docker routes all stdout and stderr of the running application to a logging engine. By default it is routed to a log file and can be viewed running this command with the name of the desired container.

“docker exec -it /bin/bash”

This is a really helpful docker command. It allows you to execute a bash into a running container. Let’s say you want to see the inner configuration of the image, the inner filesystem or even the environment variables, then you can attach yourself to the container and “cat” the configuration file, “ls” the filesystem and more.

“docker save -o .tar” (and its brother “docker load -i .tar”)

Let’s say you have built your image and you want to move it to another location. You most probably will connect to a local/global image artifactory, upload it there and then “pull” the image from the other location. But what if you need to use the image in an offline scenario? You can “docker save” the image as a tar file and then “docker load” the image in the other location.

Some architecture decisions made when working on Docker

Making the new system whilst knowing it will work on Docker, made some architecture guidelines.

No monoliths! Working on Docker really pushes you to work Microservice-ly. When you start to work with Docker and realize how easy it is to start a new image, duplicate it and change it, you realize that there simply isn’t a way a monolithic system is the better choice.
You really focus on the logic. You don’t focus on how and where to write the logs, on where the configuration will be or other stuff that distract you from just writing the logic of this microservice. You know that Docker will take care of that.
You can use whatever language and packages you want! Just make sure the image you’ll build contains them and you are good to go! In Dev/Test/Prod environments you’ll just need to make sure Docker itself is installed and voila!
No more thinking of what port I haven’t used yet. As Docker makes a bridge from your host machine to your container, you can use the same port for all of your microservices and just change it in the container.
And more…

There is a difference when making an architecture that is based on a containerized environment, and if you are an architect, you must realize this from the beginning and take this into account. It can save you hours of overthinking and over-designing.

(Not) Using Docker on Windows

Javi — Sat, 03 Jul 2021 12:56:34 +0000

Introduction

I’m a Windows Boy. That’s it, I said it. My first computer was a DOS when I was 4. My father has programmed it to play a game if I write my name and press enter. At age 6 we installed Windows XP and a whole new world appeared in front of me.

I continued the normal path of Windows Vista (Why), Windows 7 (Thank G’d), Windows 8 (Mmmm), 8.1 (Ok, Ok, back to normal), and now Windows 10 (finally). I work with Windows Servers as well; Windows Server 2008 R2, 2012R2, 2016 and even Windows Server 2019.

I know Windows pretty well. I wrote C++ programs that interact with Windows Internals. Even wrote a small filter driver. I’ve installed and configured more Windowses than I could count.

So, following this introduction, you can see why my first thought was to install Docker on Windows.

I asked another team, which had more practice using Docker, what they thought. They threw me away and told me I was being silly, “Docker should be only on Linux”. I asked why? there’s such a nice GUI for Windows..
Without a good explanation, I thought they were wrong and they just haven’t had any experience working on Docker for Windows. I went on installing Docker on Windows.

This is my story

The installation

First, you’ll need Windows Pro or Windows Server to install Docker. It won’t work on Windows Home. No problem, I thought, and updated my local version to Windows Pro. Then the installation went pretty smooth. The installation finished and a reboot was made.

Don’t they love reboots in Windows? It feels like there can be a good installation without a nice reboot at the end. Oh, your installation doesn’t require a reboot? That’s a petty…

After the reboot I opened up Docker and the nice GUI showed up. The Docker icon on the tray showed the “Loading and Unloading” animation for a few seconds. And it continued. And on and on and on. No worries I thought! Maybe another reboot will help? I preferred to ask my old good friend Google. They recommended installing WSL2. I had version 1 and I know 2 > 1 so 2 sounded like the correct way to go. After installing WSL2 (and rebooting) Docker started to work!

Looking backwards this was the first red flag. Too many things were “hard” at the installation phase. That shouldn’t happen.

The first run

After Docker started to work, everything else did it’s job correctly. Docker Build, Run, Load, Save and such worked as they should. But that only happened after Docker started running (obviously). Restarting Docker, or restarting Windows was nearly impossible to do straightforwardly. I almost always had to make 2-3 reboots until Docker was ready to work.

This was red flag #2, it’s like the G’d of Windows, Linux and Docker were shouting at me and I decided to ignore it.

The first bug

We have an app that sends packets over UDP. (Who hasn’t right?) The app worked perfectly outside Docker, but for some reason it didn’t work from inside a Docker container. After a few hours of debugging and logging and breaking and whatnot, we found out that Docker for Windows won’t pass any packet bigger than MTU from inside the container to the host. I mean, why? But fine, we changed the configuration so it would send packets of maximum MTU size and it fixed the issue.

This should have been the last red flag right? But no, we fixed the issue and everything else worked fine, when it worked, so why change anything?

The Last Straw

I wanted Docker to write all the logs to a file. A simple supported task. I read there was a simple configuration that you can tell Docker to route all stdout and stderr to a log file. You can even configure how many files and of what size they should be, pretty cool! I got stuck trying to understand where the files are. Really. Some said it was under %appdata% but nothing was there.

And then I found it. The log files are saved inside the Hyper-V image holding the Docker. WHAT. What should I do with that? How can I configure FileBeats (for example) to read that? That was it. I couldn’t find any more excuses to continue using Windows.

The salvation

I installed Linux. Ubuntu 20.04 in my case, but that doesn’t really matter. In a matter of 2-3 hours, I’ve changed my two VMs from Windows Server 2016 to Ubuntu 20.04, installed Docker, uploaded my images, configured the network and tested the App. And all that without making a single reboot!!!

Docker worked as expected from the moment I installed it. The log files appeared and I could see them without making loops in the air. Docker started and restarted as expected whenever I needed. I saw the light.

You can tell me it is obvious that Docker works better on Linux. Even on Windows it runs on Linux (WSL). But I never heard a real reason why, or a painful experience to really understand why. This is why I wrote this post, to tell my story and warn others.

Please. For your own sake. don’t use Docker on Windows.

If you enjoyed reading this, you might enjoy other posts I've wrote! Check them here

How to update yourself

Javi — Sat, 09 Jan 2021 07:00:58 +0000

Every post I write is based on my own experience and it's brought to you to help you learn from my mistakes

Do you follow any Design Patterns? Why those? Is it committed and pushed to a repo? Is it easy to understand for next versions? Will anyone (that it isn’t you) be able to pick up from you finished? And more…

At the beginning, in my job, I was assigned a “mentor” that was able to make me aware of those questions. After about a month and a half I was (apparently) prepared for my first assignment.

I had the opportunity (later realized how rare this is) to build a new project from scratch. When I say “I” I mean a co-worker and I. Thankfully my co-worker didn’t really care for this new project, so the main parts were mine to create.

This system was a Server-Client kind of system and was designed under a lot of constraints my company required.

It was all in C# and we used files to communicate between the modules. After the client would be deployed, there would be no way of contacting it but with our server, no manual intervention could be done. I was a bit afraid the client won’t work as intended (being this my first project…), so one of the modules I worked very hard on was a self-update module. You could send the client a new version of itself and it would self-update – Cool!

This module made me ask myself the following question:

How the software can change its own files while running?

Apparently there are (at least) two ways:

Dynamically write a batch file that will do the update itself. Run it from your application and exit your application. Add a delay in the batch file to allow the application to close before you start changing the files in the batch file. Run the new application from the batch when finished.
Apparently, Windows has this feature/bug (never found out) that allow you to rename files even if they are in use (doesn’t work for Office files, but for Dll’s and Exe’s it does!).
So you could use this to replace your files!
I chose option #2 for my self-update mechanism, it seemed more clean to do it this way rather than creating an awful batch file.

The idea was this:

If you receive a self-update package, rename all of your files (append “temp” for example) and copy the new files to your folder (thus replacing the old ones). Finish with restarting yourself (Using a small batch file to re-run yourself after you exit). If any of the steps fail, rename the files back.

This little feature made me really happy!

I probably tested this feature twice as much I tested all the others.

Three years have passed from that, and we didn’t need to send a self-update to fix anything. We sent it to upgrade the clients to have more features (and it worked!)

Not only the client was able to self-update, I felt I have updated myself. This project took me approximately half a year and being the first half year of my work life, it taught me a lot.

Here is a list of stuff I think worth mentioning about my experience.

Always be prepared to changes in the requirements. In my case it was constraints that were added and more features.
This means that all the Design Patterns we learned are really important and can really make the difference.
It sounds like a cliche and we hear it all the time but it is real. Clients don’t know what they want and don’t know what you can offer them. Sit with them and listen to what they really say when they say they need “X”.
Don’t underestimate the power of tests (but don’t overestimate them). “Tests are good as the person who wrote them”. You can easily have a 100% covered project that doesn’t work.
I didn’t write automatic tests for this project and I regret it to this day.
If you don’t have automatic tests that really check your code, you are writing legacy code (more about this in an upcoming post).
You want the next person that looks at your code (let it be yourself) be able to make changes and updates easily, automated tests are a huge part of this.
Projects from scratch are awesome and very rare! If you have the opportunity to write something from scratch grab it with both hands and don’t let it go! It is really rare (unless you work in a start-up I guess).
Why It’s awesome? Because it lets you be creative and you can build it as you want. Moreover, I think you learn the most from creating something from scratch rather than adding feature to an existing code-base.
Being new and an outsider is actually a good thing! I came fresh from the outside. I wasn’t narrow minded and could see things with a fresh look. A lot of things I said where indeed pretty null but a few were good and improved the system and other projects. Don’t be afraid to speak up.
It’s OK to ask questions. Actually, it’s not OK to not ask questions.
You might think you are the best but rest assured you are not. Your co-workers probably have more experience than you have, and even though they don’t know everything about what you are working on, I’m sure they can advise you and will be happy to (no one loves anything more than showing they know something…)
Write your code like the next person who is gonna look at it is a mad-alcoholic-axe-holding-nothing-to-lose guy. After three years of that system, I sometimes look back at the code and swear the guy who wrote that, then I remember it was me.
Most of the code I write nowadays is one I’m happy to look back at it and it really makes me joy to know I wrote that. (Most, not everything)
I’ll talk more about this in a future post.
You know nothing about development until you have worked on a real project (with clients, managers, co-workers, QA team and more). There is a huge difference between coding for an assignment and coding for your job. This too will have a future post.
This project is up and running up until today and will probably stay online for a few more years.

I would love to hear some of your experiences of your first project on your first job, I think each one feels a bit different and can contribute from its own experience.

See you on my next post!

(You can read more like this on my blog!)