Understanding Product Development Process

👉 Setting Up Project Environments

As the name suggests, the project environment is the space where your project executes. Once the developer has developed the particular code, he then would be putting it on a test environment where the code runs and the developer can check for bugs. Once the segregated module is tested, it is then tested for integration- connecting it with the rest of the software and APIs. Once that is done successfully, the code is then deployed to the main server (production server). This is where real users can now use the platform.

There are different project environments required for each action so that each action can be separated from the other and as a team as well as a business owner one knows the progress as code moves from one stage to another.

Thus, keeping the above in mind, one needs to set up the following environments.

Development And Self-testing

This is where a developer writes the code and would usually be his own machine and may be some cloud space for testing. The developer can himself test use cases or the code can be passed to the QA person who would test on his machine.

It is important that testing is done by another person and not just the developer as the developer may just consider the scenarios which he has taken while building the code and not the boundary cases. A dedicated QA can go deeper in testing and can also check the code with different manual and automation tools.

Once the tester is satisfied, the code moves to integration testing.

Integration Testing

During Integration testing, the developer tests the product with different 3rd parties that the product may be using like Facebook, Google maps or any 3rd party SDKs. All such 3rd parties provide their own testing environment and test data to test.

Staging

After getting satisfactory results, the developer then sets the product on a staging server which is where the product gets tested with real data. Testing with real data is important to make sure that you have not ended up with just a common or best case scenario dataset. Setting up a proper staging environment is crucial for proper testing and hence success. The staging environment should be set on the same server as the production is so that any issue with your server is found and rectified too.

Production

This is where your live application runs and as you may have guessed, your code is finally deployed to the production server where it becomes part of your main application. A production deployment process set up in advance makes the process repeatable and predictable. The more, everything is tested in advance, the lesser headache for you at the launch.

👉 Setting Up Code Repository

A code repository is a place where your code resides. When a developer writes code, they would upload the code into the repository. It is also called Source control.

In contrast to saving code on their own drive or on a Google drive, a code repository provides many advantages such as

Branching of code which means your code is divided into sections and changes can be done to one section at a time and merged with other branches once work is done easily. Version control which means in case of issue one can go back to the earlier version. Access control on who accesses what. Scalability to add multiple people or teams to the project. Integration with various project management and communication tools like Jira and Slack make you and your team effective. Given these advantages, code repository is must for managing and storing code as your product develops. Popular Code repos are Github, Bitbucket and Gitlab.

One often asked question is the difference between GitHub and Git.

Git is the version control system that you use to manage code. GitHub is the platform on which you use Git.

• Control- System to record changes over a period of time so that you can fall back to any of the past systems in case of any issue faced.
• Commit- To put code into the Git. This has to be done explicitly. Code does not saves automatically
• Fork- Creating a new copy of Other words that would often be used related to Code repository are
• Repo- The directory or storage space where your code lies
• Version the full repository
• Clone – Copying the repository on your own computer
• Branch- Copies of the program made to make changes. Unlike Fork, these copies are part of main program and would not have independent existence
• Pull Request- The act of merging a branch with another branch or the project file
• CodeCommit- Saving your code into the repository

Practices such as branching and Fork are used by developers to take a specific part of code and limit their new work to that only so that in case of any update goes wrong does not impact the whole code. Imagine, if you were building a webpage without the ability to undo or redo the facility. Anytime you write something wrong, you have to start new how difficult would it be?

Keeping the practice of branching code also allows the team to insert good practices like code review, code checks, etc into these smaller daily activities. Like you can create a rule that there should be a code review before every pull request or the code should pass through these certain tests, at every pull request. If there are any issues found, the developer can fix the issues and then redo the pull request procedure.

Additionally to make sure that code is regularly being worked on and changes are visible, code commit frequency can be set up in the team. Unless a code commit happens, the team can never know what is being worked upon. One of the early signs of project failure is the irregularity in code commits. When you do not even know if developers worked on the code or not, or the developer told that he/she is working but there is nothing to show for 2 weeks, understand you are already in trouble.

Code Commits and Branches tell you that work is being done, updates are being made and so on. Now, the important part is to understand whether the code executes properly or not. This is ensured by a process called Continuous Integration and Continuous Deployment (CI/CD).

Going back to the above example of building your website, the CI/CD is like the autosave and auto publishing with self checks built in.

Continuous Integration automatically checks for errors and runs tests on the code to make sure that new code integrates properly and does not cause any breakage. The tests can be pre defined or added on the go.

Continuous Delivery automates the deployment to the various environments- your machine, testing environment, staging and production.

By automating, you reduce the human tasks as well as human errors in these processes. The different parts that we learnt above like code commits, integration, deployment etc can all be automated, measured, monitored and even trigger an action. This setup and continuous improvements are together called the DevOps process.

Your team can build a DevOps process and can even set up a dashboard where you are able to visualize the logs, security, errors etc at one place.

At Mindbowser, we have built the dashboard using Elk and comprises of log monitoring using which devs can easily check application logs instead of having to gain access to servers.

Monitoring server usage Network Traffic Security protocols Compliance violations related to HIPAA, GDPR etc