UX first, working agile, innovation tracks and proper project governance aim for the right tools to achieve this. This article describes the Rombit journey and plans to fit the future, together with the right tech stack and Azure DevOps pipelines.

Let me start saying I am currently working at Rombit as a Solution Architect (SA) and meet on a regular base with other SA’s in our organization. Together, we’re defining and following up a roadmap on a technical level towards a more design thinking (UX)simple, agile, and transparent architectural project and product organization. Let’s call it enterprise architecture with an MVP approach.

As being part of the SA team, I wanted to highlight one of the most important building blocks that actually should act as the glue between all our components at Rombit. We have set up a couple of targets while adopting Azure DevOps Pipelines🚀

Targets

  • Faster and easy setup of new projects and POCs 🚀
  • Build an artifact and deploy anywhere, any time & move the artifact around without rebuilding the container(s) 🚢
  • Proper setup for more integration and test automation 🤖
  • Get fast test feedback by end-users by deploying more often into production 😎
  • Structured, UI driven tool with support for access control 👮, better password management 🔑 , and governance 🏛

Azure DevOps Pipelines?

Azure DevOps Pipelines is a fully-featured continuous integration (CI) and continuous delivery (CD) service. It works with your preferred Git provider and can deploy to most major cloud services, which include Azure services. You can automate the build, testing, and deployment of your code to Microsoft Azure, Google Cloud Platform, or Amazon Web Services. 🌤

Rombit’s tech stack history

A couple of years ago, we had Symfony (PHP). CI was done via Wercker and CD got triggered locally on a computer via a tool called Capistrano (Locally? 🤔 Yes. 😱).

Result: Various personal architectural flavors depending on the project and unstructured and chaotic deployments.

Shortly after that time, it has been decided to introduce Jenkins. Then, also movements from Digital Ocean infra to the first EC2 machines on AWS were a fact. The way of working started to change, and it already indicated that a CI/CD tool like Jenkins forced us into a new, more flexible way of working. Next to Jenkins, Rombit also had set up a Kubernetes cluster. All being part of a wave of infrastructure improvements.

Result: The main result was that a lot of new technologies popped up alongside and improved tech stack, which included a move to Java (which was also driven by hiring possibilities) and where PHP was phased out. Next to that, Ansible and Jenkins files (Groovy) started to show up in every repository and were maintained differently. It had/has its challenges. ⚡️ Nevertheless, it helped us to become the organization we are today, although it seems to have its limitations as well. 

Where are we today?

Our Kubernetes’ infrastructure and the neverending improving agile way of working demand a very flexible and mature way of moving artifacts towards the next phase in a project while guaranteeing the quality and scalability of a project. Releasing more often, in an autonomous way, are key takeaways of what we are working towards. 💡

The technology we use allows us to do so, but is not structured to hook into our thoughts about release management and quality, yet.

The right tool for the right job

These days we have set Spring Boot (Java) and React (Native) as defaults in our tech stack, together with a couple of supporting technologies such as Node.js and Python. Hosting & scaling? Kubernetes! Database? PostgreSQL. We also adopt a couple of exciting technologies for data engineering and ML for which I would love to refer to a previous blog post: Computer Vision with Jetson nano. 💪👌 (it’s only one of the examples)

The right tool for the right job, that’s our ambition, but it needs some glue to keep it together. Transparent and flexible. That’s were Azure DevOps pipelines comes into the picture.

Jo Somers

Examples, such as not always split CI from CD, a secure but not straight forward password management, not a very good oversight per project in Jenkins, Jenkins (plugin) management 😢, hard to heavily invest in test automation and we have to deal with wild-grown Jenkinsfiles and Ansible configs across many repositories… 

Example of CI and CD tight together in most projects today.

It allows us to start optimizing the process and our infrastructure.

Reaching our targets with “Azure DevOps Pipelines”

While Jenkins is an excellent tool to implement all of this, it just seems to need more (plugin) management and returns easier into a mess. It takes time we don’t want to spend since Jenkins was self-hosted and acts as a Swiss knife with a Groovy/Ansible configuration everywhere. With Azure DevOps pipelines, we actually can reach the defined targets set in the previous “targets” paragraph. 🙌

It also allows us to set everything up, doing it “right” from the first time while taking an audit of the setup and infrastructure of our currently running projects and getting us, as an organization ready for the future. At least it forces us to adapt and review our processes. 

We do not consider Azure DevOps Pipelines as the holy grail, since it also has its limitations. However, this way we can achieve our previously set targets, preparing for the future. 

Example of CI and CD set apart. Already integrated into some of our projects.

As you can see in the image on top, we love to split CI and CD and it’s working well with Azure DevOps.

Example of CI split apart from CD release stages in Azure DevOps pipelines with a release approval.

Full Stack Meetup

On 18 december 2019,  Gie Spaepen and I presented this approach during the Full stack meetup at our offices, looking for feedback in this new era we are entering. We have set ourselves the target to deprecate Jenkins from June 2020 🤓. Ambitious? Yes! But it will make us faster 🏃, better 🔝, stronger 💪.

The slides can be found below and since we’re still open for feedback, don’t hesitate to reach out to us!

Slides are owned by Rombit (Gie Spaepen & Jo Somers)

Wrapping up

The adaptation of Azure DevOps Pipelines at Rombit is crucial in our way of following up a roadmap towards a more design thinking (UX) project approach, simplicity, agility, and transparency. It acts as the glue between some of our processes and allows us to be ready for the future while reviewing our current tech processes.

Key takeaways:

  • 1️⃣ Enable design thinking (UX)& delivery;
  • 2️⃣ Enable faster releases;
  • 3️⃣ Enforces to take up the right roles and responsibilities;
  • 4️⃣ Ensure more quality in pipelines;
  • 5️⃣ Review our current infrastructure and tech stack;

About the author

Jo Somers (29) is a Solution Architect at Rombit.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.