Context So you have a typical project with a backend API and a frontend app built with React or Angular. You want to ensure that every time you push changes to production, they are thoroughly tested and deployed. To achieve this, you set up a CI/CD pipeline that handles the building, testing, and deployment processes automatically. At first, everything works smoothly, but as your project grows, you notice the pipeline is taking longer to complete.

People in the tech industry are often criticized for their lack of “soft skills.” I don’t know about other industries, but working in tech, I find this to be true and I’m not immune to this either. A common example of this are online forums (ex: StackOverflow), where developers may swiftly mark your question for closure or down vote it. You’re lucky if they specify the reason for their decision.

Using real-time communication with SignalR allows users to interact with the application without needing to refresh the screen to get updates. This post provides an overview of setting up SignalR in a .NET Core application. In this example, we’ll use a .NET Core API as the backend and Angular as the frontend. We implemented this type of communication on dashboard pages to display workflow status details. Backend implementation .NET Core API After you include SignalR package in your project, register it during startup.

So, you have database changes—either schema or data changes—that need to be implemented and rolled out across various environments. One approach could be to connect directly to each database server and execute scripts. However, you might not—and indeed, probably should not—have direct read/write access to certain environments like beta or production. Additionally, consider if a client posed the following questions; would you be able to easily respond? What is the state of the database in our Production environment?

This post continues our series on AI and ML. The aim is to enhance understanding of the main types of machine learning, explain the reasons for choosing the appropriate ML approach, and describe the data requirements for each method. Ways to learn There are three main ways of learning in machine learning. Supervised learning Unsupervised learning Reinforcement learning How would one choose an appropriate learning method? Appropriate ML method Selecting the appropriate machine learning method depends on your objectives.

Earlier this week, I participated in a two-day, hands-on introductory course on Machine Learning and AI, which was useful for someone new to the field like myself. The course helped me understand various concepts I had been curious about, including: The relationship between Machine Learning and AI. The definition of a “model” in this context and the process of “training” it. Clarification on terms like “Hugging Face” and “Llama.” The importance of quality data in machine learning projects.

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.