Devops

The front-end for “Employee Referrals” — the department where I work — at Radancy is a single page web application, served as static assets by nginx, which also acts as a reverse proxy. The problem Historically, the front-end team at “Employee Referrals” has followed a practice of working on features in long-running git branches, iteratively adding small changes to the branch until the feature is complete, at which point they merge it. While this (somewhat) worked when these front-end developers were part of a dedicated and siloed team, it doesn’t really work well with our new team structure — cross functional teams where front-end and back-end developers work together on product features. The need to wait for merging these long-running branches to the main branch before seeing the corresponding features on our pre-prod environment qa resulted in significant delays. This meant that it took quite a long time before other team members — product owners, testers, other devs — could test out new features and provide feedback. I wanted to get rid of this delay by allowing previews for front-end feature branches. ...

We use Jenkins for continuous integration and continuous delivery of software in my team at Radancy. Jenkins then sends a notification to a Slack channel (a dedicated channel for monitoring needs) when a deployment is through. When I joined Radancy last year, these notifications looked like this: As is clear in the image above, these notifications do not convey a lot of information about the change that is being deployed. The most useful piece of information in these notifications is a link to the Jenkins run. We use Bitbucket for source code management — we’re migrating to Github soon — which doesn’t have the best user experience for viewing commits, and doesn’t have a feature like Github Actions, so I was stuck with using Jenkins to improve these CICD notifications. ...