As an IT-consultant (in Azure, Windows Server, VSTS etc.) I often visit customers to give them advise or do an implementation. A lot of customers are building their own applications. I noticed that the development department and operations are very often not aware of the activities they are doing. For me as an IT pro with the background of a software developer it is very clear what a (good) development department is doing. In this blogpost I will explain thist to you.
My goal for this post is to clarify the software development process. In this post, I don’t want to get in details, I will explain the processes of software development in a high level. I will also mention tools (mostly Microsoft tools) that can be used to support these processes.
Agile Scrum a framework that can be used when building products. Scrum is helping by splitting big chunks of work into smaller pieces. All those small pieces of work are forming the product backlog. The product owner is the owner of the backlog and can manage it. The scrum team (a multi multidisciplinary team of developers, testers, architects etc.) are working on the small pieces of work that are at the sprint backlog. The sprint backlog is a small set of work from the product backlog to which the scum team is committed to deliver during the sprint. Once work is in the sprint backlog, the product owner is not allowed to change the work or reorder it. Every day the scrum team is doing the daily standup. This is a meeting where all the team members are synchronizing their work with each other and address issues. At the end of the sprint all work that has been done is removed from the backlog. A new sprint can start!
Please check this video about scrum. It will explain the whole process within 10 minutes!
Phase 1 – Requirement Analysis
The overall development process starts with requirement analysis. In this phase, all requirements for the software are gathered. Most requirements are gathered via interviews, workshops or scope studies. There are often two types of requirements defined:
- Functional Requirements – These requirements describe functionality of the application/product that is being developed. An example for a functional requirement for a webshop could be: “As I user I want to be able to put products in a chart.” Functional requirements are often described as use cases, user stories or in gherkin language.
- Non-functional requirements – These requirements do not describe functionality; they are more describing work that needs to be done before a certain piece of work for a functional requirement can be done. An example of a non-functional requirement could be: “We need dependency injection to have the application working with plugins” Non-functional requirements often described in an architectural design.
The requirements are defined as workitems on the backlog. Periodically the scrum team is walking through the backlog and reviewing the requirements. If they think a requirement is “development ready” the requirement can be added to one of the next sprints. If the requirement is not
It is very important to have both functional and non-functional requirements picked up by the scrum team. If only functional requirements are picked up (functional requirements have the most value for a customer), the technical debt (time to solve all technical issues) of the codebase will increase. A high technical debt will most likely lead to a slower implementation of new features or errors/failures of the application in production.
Phase 2 – Development
After the requirement analysis, has been done, it’s time to start coding. In the development phase the scrum team is realizing the product. Every sprint they deliver a working product that includes new the functionality that is developed during a sprint.
Most of the program languages today are object oriented. This kind of languages are using the concept of “objects” that contain data (also known as attributes or fields) and code (also known as methods or functions). In object oriented languages computer programs are designed by making them out of objects.
Together with the code of the application, a developer is also creating unit tests. These tests test small pieces of the application, for example a single method of an object. Unit tests are used to test on proper function of a method. When the code is changed over time (for example, for performance improvements), running this tests will guarantee that the code functions the same as before the change was applied.
After a developer has finished writing a small piece of code, the code (with the unit tests) is checked in into a repository. A mutation in the repository is called a changeset. All changesets are saved separately in the repository. Therefore, undoing a changeset is very easy. Popular repositories are GIT, TFVC, SubVersion.
Phase 3 – Building, Testing and Packaging
After a couple of changesets are checked in into a code repository, it may be time to compile the code into an application, test it and package it. These activities are often grouped together in the build automation process. The build automation process is running on a build server.
Compilation means that the compiler is transforming the code written in readable programming code into another (most likely unreadable) code. This output code can be executed on your PC. Not all output code is directly running on the hardware of your PC. In a lot of cases the application is running in a software environment (for example .NET or the Java Virtual Machine).
The second step in the build is testing. During this step the build process is running unit tests that are written earlier. The result of the unit tests is saved with the report and artifacts (the real application) of the build. The build process is also keeping track of the lines of code that are tested. With this information, the code coverage can be calculated. The code coverage is expressed in percent; and it means the percent of lines of code that is covered by unit tests.
The third step is packaging. In this optional step the binaries are packaged into an installer or installable package. Often applications are packaged in a setup package or IIS deploy package. In a lot cases packaging is not desired, the output of the build then only exists of binaries.
Phase 4 – Releasing
In the last phase of the development process the application is released and deployed to a series of staging environments. This is also called DTAP. The most common stages (environments) are:
- Test – In this environment the testers are running their tests. A good tester is automating his tests. As a result of automating these tests, the test can run automatically after deployment. In an ideal case the testenvironment is rebuild for every testrun. By doing this, tests are always run against the same machine with the same configuration.
- Acceptance – In this environment the product owner can do some final tests. If all tests have a successful result, the product owner can accept this release. In contrast to the test environment, the acceptance environment isn’t rebuild as you want to test the upgrade of the software.
- Production – After the application is accepted in the acceptance environment, the application can be deployed to the production environment. In this environment the application gets monitored and is available for it’s users.
The software development process isn’t that complicated as most IT pros think. Off course there are exceptions in which the process is far more complicated than described above. In organizations that have adopted the DevOps way of work, this whole process isn’t new. In a lot off cases DevOps engineers are already running their department with the above process. The only difference is that they don’t have to write code to develop their applications. They write code to automate things and code that will describe their IT environment (Infrastructure as a code).
I hope this post was helpful, if you have any questions feel free to contact me.