This article will be the first of a series in which we are going to explore an approach to writing reliable software on time and on budget.
On time because, as time goes on and users are not using the software, we lose market share, on budget because money is a limited resource and last but not the least, we want our software to be as bug free as possible. Let's explore those ideas and try to find a development process for building consistently reliable software on time and on budget.
The software production process will be divided into three main phases which are :
As the saying goes,
Before starting any line of code, it's important to plan and figure out all the necessary details that will go into the development of the software.
This step will be called the inception process. During this process we will list the business goals of the software(product) and we'll share them with the developers. It's important for the developers to know them so that they cant take them into account when making crucial decisions or any design trade-off.
It is important to choose a software development methodology that works best for the team and responds to the team's needs. In our case we chose to be pairing. Most developers don't like to read code unless they need to build on top of it or refactor it.
Pairing will enforce code review as the code is being written by two people at once. It also helps with the knowledge transfer within the team and if a developer should leave the team, work would continue as usual.
Software like Zoom will help with pairing. On the project management side, we'll be using Pivotal tracker, which additionally will help the product manager track the development progress.
The code is to the developer as the wood is to the carpenter, and a good carpenter need good tools in order to work his woods, a good developer would as well need good tools to work with their code. The most important tool for a developer is fully fledge editor.
A good code editor helps simplify the coding process with features like auto-completion, linting, running test automatically, integration with third-party tools like Git, etc.
Git or any other VCS system will help developers collaborate on the project faster without sacrificing the integrity of the code base and will support non linear workflow. But for all of this to work fine, we need to define a branching policy to avoid a lot of merge conflict ahead which may be a huge waste of time for the developers. Is there always a main/master branch ? How are other branches handled ? How are they up-to-date with master ? How do you solve merge conflicts ? What is the pull strategy ? Do you have branch protection ?
To complement the development process, we'll need to use a CI/CD system that will test and deploy the software automatically. Before merging, any pull request will be tested. The CI/CD process is to be integrated with the VCS for a more automated and frictionless experience. We could use Github as our CI/CD system.
After the planning and the development, it's high the time to deliver the good to the client. In most cases, deploying the product to the client is a cumbersome process that requires a lot of setup and settings.
Our first rule of deployment is Do not deploy by hand. It might seem a reasonable approach at first, especially when you are an engineer who master his craft but we know that nobody is perfect and mistakes can happen. And when it does, it might be difficult to reproduce by hand which will make it difficult to solve in case it happens. Additionally, if the person who does the deployment leaves the company, we are not sure if another one will have the same skillset to reproduce all the steps exactly in the same way, and the process wont be documented. Last but not least, it is time consuming, especially as it is a process that will be done multiple time during the development process.
The deployment process should be integrated as the last bit our the CI/CD pipeline to complete our vision of a frictionless development and deployment process.
But before deployment to the production environment, it is usually nice to have a staging area, an environment that reproduce if not all but most of the characteristics of the production environment, where we will run the integration and acceptance test to help us test the code furthermore.
For deployment, we will use docker and kubernetes.
In the coming articles, we will go in the details of each of these steps.
