At CodeLink we follow strict engineering workflows. We believe that by enforcing standard practices everyone will be able to default to routine in their workflow and dedicate their full energy to what matters: discussing ideas and writing high-quality code.
The following are our main practices in the daily developer workflow.
We rely on tracking tools such as Pivotal Tracker and JIRA, to manage projects and synchronize between members of the team. Product Owners create user stories which the development team takes ownership of and delivers.
A User Story is an atomic work unit within the whole product. A User Story holds important information required to understand the atomic work unit, such as acceptance criteria, technical notes, design links, questions and answers related to the implementation, and the audit trail of work.
Before allocating a user story to themselves the Developer reads through the requirements, checks for any discussions and comments included in the user story, and then assign it to themself.
For each User Story, the Developer creates a GitHub branch with a relevant name. The naming is maintained later when the engineer wants to merge the code then create a Pull Request for review.
As the Developer works on the user story they will comment on any important information as they make progress and update the status of the story as it moves through the development life-cycle.
Unless the Developer already knows what to do, it is encouraged that they discuss with their team members about their implementation intentions. Most of the time the work done by an individual will affect the work of others and the overall system. Changing an API payload will affect the client-side, or designing a table schema can have a long-term effect on different app logics. Changes like this must not go unnoticed.
Discussing the technical challenges with other members can help highlight different approaches others may have used in the past, saving a lot of time over figuring these out alone.
This is the part the Developer spends most of their day on. It's the fun part because this is when they get to write code. As they move through their day they commit code whenever they finish on a unit of work. The commit history then shows a story about the journey they went through to finish the feature.
The commit should be atomic, able to describe the changes in a single sentence. For example, "Added an email to the User model" is a good commit, whereas "Added an email to the User model and wrote tests for the Posts controller" is not a good commit as it combines different programming units into a single commit.
Our Developers commit often, aiming for at least one commit every hour. They make it a habit to track everything before they move on to the next task. When the task goes through peer code review, a clear commit history can help to communicate the intention of the author.
Each User Story has its own branch, and to merge code into the main branch we use a Pull Request.
Pull Requests are central to our development process. We use them to create a snapshot of changes in a feature, and allow team members to review the code. Even when the code is not ready, we recommend our team still create an early Pull Request and mark it with "WIP-"* to update their team and the client on our progress.
The Pull Request description follows a general template. The description points to the related user story, has an informative description, and provides all of the necessary information, such as deployment, testing, etc.
For all projects, we have a CI/CD (Continuous Integration/Continuous Deployment) server set up to handle deployment. The CI/CD server will run all related tests and automatically deploy. Once deployed, the Developer will manually test the deployed application. This is to prevent any situation where the application runs perfectly on the local though has conflicts once deployed to the remote environment.
To sum up the day, each individual member of the team sends out a daily report to their client. The daily report outlines what they accomplished, any roadblocks, and their goals for the following workday.