This time I’d like to touch on a few more advanced topics related to GitLab CI. The common theme here is implementing custom features within your pipeline. Again, most of the tips are specific to GitLab, but some could be easily applied in other CI systems as well. Running integration tests Checking your code with unit tests is usually easy to plug into any CI system. It usually is as simple as running one command built in your language’s toolset.
This post is a quick how-to for starting a new project in Go. It features: Hot code reloading Running multiple Docker containers with Docker Compose Using Go Modules for managing dependencies It’s best to show the above working together with an example project. We’re going to set up two separate services communicating with messages over NATS. The first one will receive messages on an HTTP endpoint and then publish them to a NATS topic.
Let me start by thanking all contributors for feedback on Watermill - it drives us to add new features. Thanks! It’s been almost a month since the initial release of Watermill. However, it’s just the beginning and we are still working hard to ship new features. What is new in Watermill 0.2? Documentation - watermill.io Godoc is great. However, it’s functionality is sometimes too limited to express more complicated documentation.
In the previous post I showed how to keep all the scripts used in the CI in one repository. Let’s see what more advanced scripts you could put in there. This time I’d like to show how to add automatic versioning to your pipeline. You will also see how to push commits to your repository within the CI jobs. But first, let’s start with some background. Picking your flow One of the things I love about GitLab is its flexibility for setting up your own CI workflow.
Watermill is a Go library for working efficiently with message streams. It is intended as a library for building event-driven applications, enabling event sourcing, CQRS, RPC over messages, sagas. Why? Lack of standard messaging library There are many third party and standard library tools which help to implement standardized RPC or HTTP communication in Golang. There are also multiple third party HTTP routers and frameworks. But when you want to build a message-driven application, there are no libraries which are infrastructure-agnostic and not opinionated.
With this post, I’d like to start a series of CI-related tips, targeted mostly at GitLab, since that’s my go-to tool for things CI/CD-related. I’m sure most of them could be easily applied to other CI systems, though. While GitLab does a great job at many things (repository hosting and related stuff, like MRs, pipelines, issue boards, etc.), it sometimes lacks more specialized features in some areas. With heavy usage of pipelines in my projects, I often had to look for workarounds and smart tricks.
Nowadays we can often hear that monolithic architecture is obsolete and responsible for all evil in IT. We often hear that microservices architecture is a silver bullet which helps to kill all this monolithic evil. But you probably know that there are almost no silver bullets in IT and every decision entails trade-offs. One of the most favored advantages of microservices architecture is good modules separation. You can deploy every service independently and services are easier to scale.