Software Development Process at JTC
In this blog, I want to share how we approach software development. JTC is an engineering company where each product engineer takes complete ownership of the feature from development to deployment and monitoring and take great pride in building great software products.
Before we start the actual development, one of our engineer (usually tech lead) gets together with the project owner (usually the customer) to understand the problems that need to be solved and solution that needs to be built. Once those are finalized, the work is converted into user stories (we follow behavior driven development) and entered into JIRA. We then begin to start executing them.
Step 1: Planning
We follow the agile methodology. It all starts with sprint planning. Team members get together on a particular day of a week (Monday in our case), talks about new user scenarios that need to be enabled as well bugs, if any, that needs to be addressed. The work is estimated in story points and planned (factoring any upcoming time offs) for the sprint. Our sprint is usually a week long.
All the work is managed in JIRA.
Key Communication:
At the end of sprint planning session, a member of engineering team (often the lead) would share the work items planned in sprint and share with rest of the team on Slack
Step 2: Development
We use Gitflow branching model and Github for source control. For every task, bug, or story, we create a feature branch.
Ex: Consider a story in JIRA: SEQP-10 – User should see an error message if they entered wrong username or password.
git hf feature start SEQP-10/error_message_wrong_username_password
We use Hubflow (a set of helper scripts) that does all plumbing work to enforce Gitflow branching model. Hubflow can be installed using following instructions (for Mac/for Linux).
Once all the changes are made and automated tests are written, changes are committed. At this stage, the engineer who made the change goes to Github and raise a pull request (PR). With each PR, they write a detailed description of the changes made, document manual test cases ran, automated tests cases added, and various devices the changes were tested. S/he then assigns relevant engineers to review the code. With each commit, our bot ensure that changes follow coding standards and run all automated tests to ensure the changes do not break existing scenarios. In case it breaks, our system does not allow the commit. Our system automatically deploys just those changes to a new endpoint (for web-based projects). Each PR goes through a detailed code review. Here are a few things a reviewer looks for:
- Proper comments have been added to the code.
- Variables and functions are named correctly.
- Proper validations and null checks are in place.
- Relevant automated test cases have been added to cover new code path.
- Proper error logging is done to ensure we can debug the issue in production in case an issue occurs.
- The code is architected correctly and follows SOLID design principles.
- Think about all various scenarios these changes might affect.
- For UI related changes, does user experience make sense? Is it responsive? Does it render well when user zoom in or zoom out?
- Performance implications (time and memory)
Step 3: Merging PR
Once the reviewer approves the changes, the developer merges the PR as follows:
- Checkout feature branch locally
git checkout feature_branch- Merge latest changes from destination branch into feature branch
git pull origin destination_branch- Rebase (to ensure your changes are at the tip of destination branch when merged)
git rebase -i origin/destination_branch- Push your branch changes forcefully to Github (your origin)
git push -f origin feature_branch- Squash and Merge (second option in dropdown in Github when trying to merge PR) so there is only commit made for the PR (and not the full commit history of PR is carried over)
Once the PR is merged and developer moves on to next work item. Note that we do not have a separate QA team and our engineers own everything from building the feature to testing and monitoring. As soon the changes are merged, our system auto deploys them to a staging server.
Key Communication:
Before start of work day, every member of engineering team shares their daily status update in PPP format.
Progress:
---------
...
...
Plan:
------
...
...
Problems:
---------
...Step 4: Sprint Exit
At the end of the sprint, the engineering team demo the work to product team (often our customer). Once the changes are accepted, the tickets in JIRA are moved from DONE to CLOSED state and engineering team releases them to production as follows:
JIRA:
- Create a release in JIRA. We follow semver to determine
<release-version-number> - Associate all
CLOSEDsprint ticketsFix Versions(s)with appropriate release
Git:
- Initiate release via
git hf release start <release-version-number>. - Bump the package version (Eg:
versionfield inpackage.jsonto<release-version-number>). Commit that to release branch created above. - Finish the release via
git hf release finish <release-version-number>. It will open editor twice. On second prompt (associating notes with release tag), copy the release notes from JIRA and paste on second prompt.
Key Communication:
Once the changes are released to production, a member of engineering team (often the lead) share the JIRA release notes with rest of the team on Slack.
Step 5: Hotfixes
We have set up monitors on our servers and if there are any errors, bug or crashes that happens, our team gets immediately notified on a Slack channel. In case, after the release, any urgent defects are found, the team would do a hotfix to mitigate the issue.
JIRA:
- Create bug(s) for the defect found in production
- Create a release in JIRA. We follow semver to determine
<release-version-number>. Hotfix should generally update onlyPATCHnumber - Tag bugs in JIRA that needs to go out with hotfix.
Git:
- Initiate hotfix via
git hf hotfix start <release-version-number>. - Work on bug(s) by creating separate feature branch for them as follows:
- Create feature branch for the ticket that needs to go out with hotfix. The feature branch should derive from hotfix branch instead of
developbranch.git checkout -b feature/TICKET_NUMBER/TICKET_DESCRIPTION hotfix/<release-version-number> - Raise PR against
hotfix/release-version-numberinstead ofdevelopbranch on Github. The PR goes through same review cycle as mentioned during development phase - Once all tickets are merged, release the hotfix as follows:
- Checkout
hotfix/<release-version-number>branch and pull latest. - Bump the package version (Eg:
versionfield inpackage.json). Commit that to hotfix branch created above. - Finish the hotfix via
git hf hotfix finish <release-version-number>. It will open editor twice. On second prompt (associating notes with release tag), copy the release notes from JIRA and paste on second prompt.
git hf hotfix finish <release-version-number>Key Communication:
Once the changes are released to production, a member of engineering team (often the lead) share the JIRA release notes with rest of the team on Slack.
What’s the biggest thing you’re struggling with right now that we as a technology consulting company can help you with? Feel free to reach out to us at jalantechnologies.com. We hope our assistance will help!
