DEV Community: Aditya Arpan Sahoo

My experience as a Software Engineer at DPS

Aditya Arpan Sahoo — Sat, 30 Nov 2024 09:31:25 +0000

In this blog, I have tried to summarize my voyage from an average student developer to completing 3 months at Digital Product School as a Software Engineer.

About Myself

Hello everyone, I am Aditya Arpan, a recent graduate from ITER, SOA University, Bhubaneswar with Computer Science major. I love hackathons. I’m also a community and DevOps enthusiast. Since childhood, I was interested in web technologies. After joining college, I spent a lot of time googling about various programs and opportunities and applying for them while learning and building simultaneously. I also met a lot of folks over LinkedIn and Twitter and learned from their journeys. It helped me to gain many experiences regarding student programs, hackathons, communities, and open-source.

Working with Digital Product School has been one of the most wholesome and fulfilling experiences that I have had on a professional level this year. It has been a career-defining opportunity for me and it is truly my privilege to document and present my journey with DPS.

Applying For The Role

I heard about DPS Fellowship through a friend who was working there as a full-time Software Engineer. As I was looking for professional exposure and industry experience, I saw this as a great opportunity to get more involved in the Software Engineering domain. Out of curiosity, I sent a mail to DPS Team with my resume and portfolio to see whether I will be a good fit. The response has eliminated all my doubts and given me the confidence to pursue the Software Engineering Track (Thanks to the team for this). After that, I joined #askDPS which is a zoom meeting with the DPS Core Team where you get a chance to interact with them directly, ask questions and get all information you need before you proceed with your application.

After filling out the application form, which primarily asked for my personal details along with my resume and a detailed cover letter, I got back to my normal student life meanwhile waiting for the result.

Then on March 2021, I got a call for an interview after my application got shortlisted. The interview was very smooth. It was more like a discussion rather than a typical interview. I asked a lot of questions about “life at DPS” to my interviewer out of curiosity. It was pretty fun. After about a week, I got the acceptance letter and it was a great day for me since it was the first time ever that I was accepted into a fellowship/internship program.

Program Structure

The Digital Product School (DPS) is a 3-month full-time fellowship program (open to students and working professionals across the globe) that teaches not only problem-solving processes using design-thinking, agile and lean principles, and techniques, but also the ways to perform them in reality. It is organized by the Digital Mobility Hub of UnternehmerTUM GmbH, Munich.

Our batch (batch #16) started on May 9, 2021. All of us (the Core Team and the participants) met together online for the very first time. As the cohort was in hybrid mode, DPS organized a refreshing hike on the Bavarian Alps for the on-site participants(Too bad! I missed this. I’m still having the FOMO). With this, we had an amazing opening session and met our Track Heads, got assigned to a team, met my teammates, made some new friends in random breakout rooms, and a lot more.

For those who are wondering about tracks, this program consists of 6 tracks i.e. Interaction Designers(IxD), Software Engineers(SE), AI Engineers(AI), Product Manager(PM), Agile Team Coach(ATC), Product Marketing and Communications Manager(PMC). All the participants in a batch were divided into groups with each team consisting of 1 PM, 1 AI Engineer, 2-3 SE, 1 IxD, and 1 ATC. All the teams are either classified as a “Company Team” which is responsible to find solutions for DPS Partner Companies or a “Wild Team” which is free to propose a solution to any valid problem of their choice (usually these teams find solutions for problems existing in DPS). In the end, I was assigned to a company team “Sharespacers” having 6 members in total, 1 PM, 1 IxD, 3 SE, and 1 ATC.

The DPS 3-month program is divided into 12 weeks and each week has a goal (which is called the weekly design sprint). Each team tries to achieve a weekly goal and presents it on-screen to everyone (usually presentation slides explaining the problem-solving approach, Figma prototypes, or even a mockup of their final MVP — Minimum Viable Product). Each team is also assigned a mentor who along with providing guidance, and mentorship takes care of things like each member is going in the right direction. As DPS is a very inclusive and diverse community, you get to work with team members with different backgrounds, cultures, and religions (also timezones :-)) which was indeed very challenging to understand each other in this short duration.

The first few weeks were full of workshops and training sessions where we were introduced to several tools such as lean DPS canvas, AI-deation, research canvas, guerilla research, scrums, sprints, bomb boards, usability testing methods, A/B testing, retrospectives, sprint reviews and so on. The next few months were pretty clear for us to start working dedicatedly. We are involved in Team Discussions, Pair Programming, Brainstorming, Stakeholder Mapping, Weekly Track Meetings, and the most important part of our program — conducting User Interviews and getting feedback. To help the team grow and avoid discrepancies, each team has a weekly retrospective hosted by a team mentor. In addition to this, each team member also has an opportunity to have a 1 on 1 chat with the team mentor and with each track head. Although I was working remotely, I was still getting the vibe of being in a proper agile environment. I was able to get out of my comfort zone and bring discipline to my daily routine to manage everything (which was very challenging for me).

We also had weekly track meetings. It was “SE Weekly” in my case, where all of the Software Engineers along with our Track Head (Daniel or Bela) has fun conversations and learning sessions about different technologies (which might be useful for our project later at some point in time, example: containerization) and problem-solving. We also talked about the difficulties that we’re facing as developers and how to solve them.

At the end of the 3-month program, DPS expects a comprehensive solution in the form of a “Minimum Viable Prototype/Product (MVP)”. It can also be a digital product that is well-coded/designed and well-presented.

The only thing I missed during this program, was being at our office in Munich. My colleagues are engaged in various games, fun activities, cooked food, outings, and have lunch together while those who were working remotely are getting FOMOs. I even missed the Final Day Spring/Final Product Review where everyone was together for the last time.

The D-Day!

Finally, it's the day when we had to show the MVP we made for our partner company, in front of everyone at DPS, along with stakeholders. It was our final sprint review where we presented the tool which we have built over the span of 3 months with a pretty good advertisement intro video and a video walkthrough of our MVP. I met a lot of resourceful folks, CEOs, and other officials. Some of them are interested in our product and specifically set meetings to go through the specifics which was a really proud moment for our team. It feels like all our hard work has paid off. Watch out final sprint review (Batch #16) here.

My Takeaways

For me, it was the first and best experience I've ever had. I can't able to explain how beginner-friendly this program is and the amount of exposure it provides. I still can't believe how fast those 12 weeks passed. Started with strangers on the team, and ended up being friends. We all started working together, played a lot of games, had conflicts, understood each other's problems and days off, did vibe together, and concluded our journey with an MVP.

I learned how to ideate, and create a user story map before making a product and taking feedback to improve further. Even through delivering a product under stress and time constraints was challenging for me as a college student (while attending college classes simultaneously), it has greatly improved my skills professionally. I learned to give feedback and also take them positively if any, make my points clear depsite of conflicts, and collaborate in making a product that can impact a lot of lives including ours. I learned React Js, docker, containerization in just a week which is insane, and some other new technologies and tools which boosted my skillset a lot. I learned to work with individuals having different backgrounds, cultures, and regions. I also learned how to work in a team, how to assist and collaborate, how to think, ideate your thoughts, and work efficiently. I also learned how big organizations work and how to deliver a product under stressful environments and within time constraints. I worked with some of the great minds around the world, learned a lot from them, and experienced diversity. I cannot even thank DPS enough for providing me with one of the best experiences of my life.

Thanks to my Team (Sharespacers): Aylin, Ejike, Madhu, Marvin, and Nayeon.

And my special gratitude to the talented DPS Core Team: Annina, Afi, Basti, Bela, Daniel, Lorenz, Marcus, Natt, Samreen, Steffen.

Hackathon 101

Aditya Arpan Sahoo — Sat, 30 Nov 2024 08:00:28 +0000

(Ever wonder what the term “Hackathon” mean? All of your friends have been participating and winning very attractive prizes but you are not? Well, this is something that you should read.)

I’m sure that many of you have heard the term “Hackathon” and the first picture that came to your mind was hacking into someone’s system using a terminal.

But let me assure you, “We don’t do that here.”

Hackathon is all about solving a problem within a certain period of time. It can be within 24 or 48 hours to a couple of weeks. It varies in different hackathons. All you have to do is form a team, and build a solution to the problem statement within that time limit. The solution can be a website, an application, or even a prototype explaining your idea. And then finally present your project/idea in front of judges.

See, it’s that simple. But it isn’t. Developing a solution and building a website or application within a short period of time is also a very challenging task. You don’t know what are some unexpected problems or errors that you might be dealing with. Your project can be perfect but may give you some errors while deploying or hosting it(which is very time-consuming if you’re using some other hosting platforms other than GitHub Pages).

Hackathon also makes you push your limits, generate creative ideas and solutions, learn time management, and work in a team. Before that, you might be sitting on your couch binge-watching movies/series, but in hackathons, you’ll be working all day and night long without sleep which is very exciting and tiring too. Don’t worry, the organizing team has got your back. For that, they have many workshops, gaming sessions, fun, and interactive sessions to cheer you up. During these moments, you will realize your superpowers of which you weren’t aware.

In every hackathon, there are an Organizing team, Sponsors, Mentors, and participants(aka hackers 🤓😎). The organizing team takes care of the whole system during the entire span. Sponsors are organizations who invest money and also look out for the best talents (who knows you might get a job/internship offer from the sponsors). Mentors are experienced folks who are always there to help and guide you throughout the hackathon, you can reach out to mentors if you face any technical difficulties or you have any doubts regarding your presentation. They’ll be more than happy to assist.

You’ll learn a lot more in those 24 hours than you have imagined. It’s a great place to do networking. Networking is the best thing about hackathons which I love the most. I have met a lot of resourceful people and made friends too. Hackathons also open the doors to many developer communities. Join those communities and get involved in the discussions, and events and you’ll get a lot of exposure and opportunities that you haven’t imagined.

Do you want to have all the fun here only? By reading? You should probably check out many past, ongoing, and upcoming hackathons on platforms like Devfolio, Devpost, and MLH. You should go for it no matter what. Then you’ll realize what you’ve been missing. There’s no guarantee that you will win your first hackathon, so what? You have experience now and perform better in the next one. Eventually, your desk will be filled up with a lot of attractive prizes and swags. You just have to keep a growth mindset and take care of your health.

Thank you so much for reading and happy hacking!

Automating Releases with Semantic Versioning and GitHub Actions

Aditya Arpan Sahoo — Sat, 30 Nov 2024 06:38:14 +0000

Introduction

Automating versioning and releases is essential for maintaining a smooth and consistent development workflow. By combining Semantic Versioning (SemVer) with GitHub Actions, you can automatically manage version bumps, changelogs, and releases whenever changes are pushed to your repository. This eliminates manual tasks, improves productivity, and ensures a reliable release process. This process is a part of the broader CI/CD workflow, ensuring consistent and error-free releases.

In this guide, we’ll walk through setting up a GitHub Actions workflow that automates the release process using Semantic Versioning.

Understanding the Setup

Before diving into the implementation, let's look at the key components we'll be using to build our automation workflow:

Semantic Versioning: This is a versioning system that follows the format MAJOR.MINOR.PATCH.
GitHub Actions: A CI/CD tool provided by GitHub that allows you to automate your workflows directly from your GitHub repository.
Packages we'll be using:
- semantic-release: A fully automatic version management and release publishing tool.
- @semantic-release/changelog: Automatically generates and updates changelogs based on commit messages.
- @semantic-release/commit-analyzer: Analyzes commits and determines the next version based on commit messages.
- @semantic-release/git: Pushes changes made by the semantic-release (like the changelog) back to your Git repository.
- @semantic-release/github: Creates GitHub releases and adds release notes automatically.

What is Semantic Versioning?

Semantic versioning (often abbreviated as SemVer) is a versioning scheme that aims to make it clear whether changes in your project are backward compatible, introduce breaking changes, or simply fix bugs. A typical SemVer version number looks like this: MAJOR.MINOR.PATCH (e.g. v1.4.8).

MAJOR version is incremented when you make incompatible API changes that breaks the current feature.
MINOR version is incremented when you add functionality in a backward-compatible manner.
PATCH version is incremented when you make backward-compatible bug fixes.

(Note: backward-compatible means the ability to be used with older/previous versions.)

Each update to the project can be classified into one of these categories, and semantic-release automates this process by updating the version automatically based on commit messages.

The Role of GitHub Actions in Continuous Deployment

GitHub Actions allows you to automate workflows directly in your GitHub repository. These workflows can run on various GitHub events like code pushes, pull requests, and more. In this blog, we’ll use GitHub Actions to automate our release process, from building to pushing version updates to the repository.

Why Automate Release?

Automating releases offers several benefits:

Consistency: No manual steps for incrementing versions or tagging releases.
Efficiency: Reduced time spent on repetitive tasks like updating changelogs, version numbers, and creating Git tags.
Error-Free: Eliminates human errors during the release process.
Reliability: The process is repeatable and can be reused across different repositories.

Automated Versioning with `semantic-release`

semantic-release is a powerful tool that automates version management based on your commit messages. It relies on the commit message convention known as Conventional Commits. Here’s how it works:

Breaking changes (such as feat!: or fix!: in commit messages) will trigger a major version bump.

  fix!: update deprecated API endpoint
  [v1.5.2 -> v2.0.0]

New features (e.g., feat: in commit messages) will trigger a minor version bump.

  feat: add new user login feature
  [v2.0.5 -> v2.1.0]

Bug fixes (e.g., fix: in commit messages) will trigger a patch version bump.

  fix: update documentation
  [v4.2.7 -> v4.2.8]

Generating the Changelog

As part of the semantic-release process, a changelog is automatically generated. Here's an example of what the changelog looks like:

# [4.0.0](<https://github.com/arpanaditya/semantic-versioning-action/compare/v3.1.0...v4.0.0>) (2024-11-26)

* feat!: major update from dev BREAKING CHANGE: major update from dev ([fac5eec](<https://github.com/arpanaditya/semantic-versioning-action/commit/fac5eec5533c1fe3432f96986403efcfadbc79ae>))

### BREAKING CHANGES

* major update from dev

# [3.1.0](<https://github.com/arpanaditya/semantic-versioning-action/compare/v3.0.1...v3.1.0>) (2024-11-26)

### Features

* minor update from dev ([606258b](<https://github.com/arpanaditya/semantic-versioning-action/commit/606258b3318929182319b29a6a81eae0fabb138b>))

Step 1: Install the Required Packages

We need to install the required packages as development dependencies. Run the following command to install them:

npm install --save-dev @semantic-release/changelog@6.0.3 @semantic-release/commit-analyzer@10.0.4 @semantic-release/git@10.0.1 @semantic-release/github@11.0.1 @semantic-release/release-notes-generator@11.0.7 semantic-release@24.2.0

Step 2: Create a GitHbu Actions Workflow

Let’s create a .github/workflows/release.yml file in your repository. This file will define the GitHub Actions workflow that will be triggered on every push to the repository.

Here’s the basic structure of the release.yml workflow:

name: Release

on:
  push:
    branches:
      - main # Triggers when code is pushed to the main branch

jobs:
  release:
    permissions:
        contents: write
    runs-on: ubuntu-latest # Runs on an Ubuntu runner

    steps:
      # Step 1: Checkout the repository code
      - name: Checkout Repository
        uses: actions/checkout@v3

      # Step 2: Set up Node.js
      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "20.x" # Use the Node.js version required for your project

      # Step 3: Cache Node.js modules to speed up future builds
      - name: Cache Node.js modules
        uses: actions/cache@v3
        with:
          path: node_modules
          key: ${{ runner.os }}-node-modules-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-modules-

      # Step 4: Install dependencies
      - name: Install Dependencies
        run: npm ci

      # Step 5: Run semantic-release
      - name: Run Semantic Release
        run: npx semantic-release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Provide the GitHub token for authentication

Breakdown of the Workflow Steps

Checkout the Repository: This step checks out the latest code from the repository so that GitHub Actions can work with the latest changes.
Set up Node.js: This action ensures that the correct version of Node.js is set up on the runner. In our case, we’re using Node.js version 20.x .
Cache Node.js Modules: GitHub Action caches the node_modules directory to speed up future builds. This is crucial for larger projects where the installation of dependencies can take time.
Install Dependencies: Using npm ci, this step installs the exact dependencies defined in the package-lock.json file, ensuring that the correct versions of packages are installed.
Run Semantic Release: This step uses the semantic-release package to automatically determine the type of release (major, minor, patch) based on commit messages. It also updates the version in package.json , generates a changelog, and publishes the release.

(Note: The GITHUB_TOKEN is a secure token automatically provided by GitHub for workflows running in your repository. You don’t need to manually create or add this token. It is preconfigured)

Step 3: Configure Semantic Release

Next, we need to configure the semantic-release package. Modify the package.json file to match your project's branches and assets.

"release": {
"branches": [
  "main"
],
"plugins": [
  "@semantic-release/commit-analyzer",
  "@semantic-release/release-notes-generator",
  "@semantic-release/changelog",
  [
    "@semantic-release/github",
    {
      "assets": [
        {
          "path": "dist.zip",
          "label": "Distribution"
        }
      ]
    }
  ],
  [
    "@semantic-release/git",
    {
      "assets": [
        "package.json",
        "CHANGELOG.md"
      ],
      "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
    }
  ]
]
}

Step 4: Commit message Conventions

Semantic release uses Angular Commit Message Conventions messages to determine the type of version bump (major, minor, patch). To follow this, you or your team should follow a Conventional Commit format:

fix: correct a bug
feat: add a new feature
feat!: breaking change BREAKING CHANGE: change that introduces backward incompatibility

We also can use tools like Commitizen Commitizen, and commitlint to enforce valid and consistent commit messages.

By using these commit messages, semantic-release will automatically determine whether to bump the version and generate the necessary changelogs.

Step 5: Push and Test the Workflow

Once you have set up the workflow and configuration files, push the changes to your GitHub repository. This will trigger the GitHub Actions workflow based on the on_push event.

The action will:

Install the necessary dependencies.
Run Semantic Release to analyze your commits, bump the version, generate release notes, and update the changelog.
Create a new GitHub release and tag.
You can monitor the progress of the workflow in the Actions tab of your GitHub repository.

Conclusion

Automating releases with Semantic Versioning and GitHub Actions streamlines your development workflow, ensuring consistent, error-free versioning, changelogs, and releases. By integrating semantic-release and GitHub Actions, you eliminate manual tasks, reduce human error, and enhance productivity, allowing your team to focus on writing code rather than managing releases. This setup provides a scalable, reliable, and efficient way to handle versioning and publishing, ultimately improving the quality and transparency of your project’s development cycle.