“Can you only add a button below this field?”, said no client ever 5 minutes after release to production.

Heraclitus, the Greek philosopher said “Change is the only constant in life”. My experience in enterprise software development led me to the conclusion that software is the same. Even when a project is completed, there are always changes: minor or major.

Additional problems arise when there are multiple changes made to the software simultaneously. This is also the raising issue with microservice architecture when multiple codebases are changed for a single feature. Knowing what code went to staging and production, what is being tested, which commit added the error is mandatory for a successful project.

So what is this Change you are talking about?

Change is a basic building block of our projects. It describes a “change” in the source code, be it fixing a bug or adding a new feature.

Change can have multiple states:

• Awaiting Change Spec – Business analyst in association with client specifies the change
• Awaiting Solution Spec – Developers elaborate on possible solution
• Awaiting Approval – Solution is presented to client
• Awaiting Development End – Developer is working on the change by implementing approved solution
• Awaiting Code Review – Senior developers review change
• Awaiting Manual Test – Change is deployed to test environment and manually tested by test team
• Awaiting User Acceptance Test – Change is presented to client for final testing
• Awaiting Deployment To Production – Change is ready for production
• Awaiting Test Failure analysis – Change has issues and it needs to be fixed
• Solved – Change is deployed to production

Suppose that we have a webshop and client came with an idea that the user must login before checkout. We would create a new change named “User must login before checkout”. Our issue tracking software will assign change number to it so it would look like this: #23445 – User must login before checkout. We will quickly go through the change life cycle in this example.

Change is in Awaiting Change Spec state and client specifies what the result should be – user must be logged in before he enters checkout. After the change is specified, state is changed to Awaiting Solution Spec where developers decide on possible solutions. It could be a redirect to the login page or popup requiring the user to login. Change is the put in Awaiting Approval state and solutions are presented to the client. When a client chooses a preferred solution (e.g redirect to login page), change is then assigned to developer and state is changed to Awaiting Development End.

Developer then implements the change, makes a Pull Request and sets change’s state to Awaiting Code Review. If the implementation provided in PR is up to the code quality standards, it is merged and change is put in Awaiting Manual Test state and assigned to the test team. Change can then go to Awaiting User Acceptance Test or Awaiting Test Failure Analysis state, depending on the testing results. When the change is Awaiting User Acceptance Test state, client checks if the solution on the test environment suits his needs. If it does, he sets change state to Awaiting Deployment To Production and if it doesn’t he sets it to Awaiting Test Failure Analysis.

If the change is in the Awaiting Test Failure Analysis state issue is returned to one of the previous states: Awaiting Change Spec, Awaiting Solution Spec or Awaiting Development End based on the reason change was put in this state.

After Change is deployed to production its state is set to Solved and the life cycle is finished.

So I can connect change with git?

If you are a software developer You probably already know what is git so I will be brief about this. The main thing I want to focus on in this section is branch and pull request naming. We have a master branch and change branches. Master is always synchronized with the test environment so every change branch that is merged with master must be ready for testing. Also there should not be direct commits made to master, only PR merges. Branch name and PR should contain Redmine change id.

For our change, git branch should be named 23445-user_must_login_before_checkout and PR name should be 23445 – User must login before checkout. If the change name is too long, you can use a shorter version, eg 23445 – User checkout login. With this naming convention we can easily connect changes in Redmine with changes in source code. PR should contain a link to change in Redmine. When PR is made, a link to it should be added to Change so it can be easily accessed.

And there is a CI in all of this ?

Jenkins is CI tool for automating testing and deployment. When PR is merged into master, Jenkins starts the build automatically and assigns it a build number. When build is finished it is deployed to the test environment. Build number should be then assigned to change in Redmine so we could track which build was from which change. Jenkins is also used to deploy builds to the production environment when change is ready for deployment.

What to do next?

We could also improve some of the aspects by automating some of the process steps. For example we could add scripts to the Jenkins pipeline to automatically set build number to change when build is deployed to the test environment. We could also add git hooks to set PR url to change. This would greatly reduce human errors in the process. When change is deployed to production, we eagerly await new changes so that the process can start again.