Run tests locally In order to test, you can spin up the docker containers locally. There are multiple things that you need to do to avoid confusion during testing. The code that is tested, gets copied over to a docker image. This means that when you make a change, you need to take care of things such as: stop running containers remove containers remove volumes that have stale data remove images for UI and backend API remove dangling images spin up new services with docker compose copy tests results into specific directory After doing this a couple of times (and forgetting to do them) it was time for automation.

The end-to-end tests set-up described in my previous post, is a series of docker containers that talk to each other. This set up is nice because, it will run on any machine. This allows you to test your app locally or in CI/CD pipeline. In this short post, I show the set up I used to run end-to-end tests. Docker compose set up In order to spin up containers locally or do so in the CI pipeline, and to run just the “smoke tests” or for all tests, I created multiple docker compose files.

In this post, I will provide a thousand-foot overview of how to run end-to-end tests in your CI/CD pipeline. In future posts, I plan to write up the details, challenges encountered, and solutions. I will show how the end-to-end tests were set up in the CI/CD pipeline. End-to-end tests verify the entire application, including the front-end, back-end APIs, and the database. These components had to be up and running in the build agent and play nicely with each other.

Overview Throughout the lifetime of your project, you will most likely wonder (or will be asked) the following: what is currently released in Production or your other environments? what features or bug fixes are slotted for the next release? are there any breaking changes?! This is where a process of release management comes in. The goal of release management is to communicate what has changed and what developers and users can expect upon the release of changes.

Overview On my latest project, I had the opportunity to explore an alternative to relational databases: Document Databases. Document Databases belong to a category called NoSQL databases. I found a couple of advantages of using a document database compared to a traditional relational database, which I will demonstrate with an examples below. Schema flexibility Let’s say you have a table that stores user’s information. Let’s store just first and last name.

This post is here to motivate me to keep a blog. I’ll list out reasons (in no particular order) and I’ll keep adding more as I think of more. Maintaining a professional blog can be a highly beneficial practice for individuals looking to advance their careers and expand their professional footprint. Here’s a breakdown of why keeping a blog can be advantageous: 1. Communication Skills Regularly writing blog posts helps develop your ability to convey ideas clearly and effectively.