The CI Story - g4gupta/try_git GitHub Wiki

Below we will try and simulate a development scenario to understand the different aspects of continuous integration process.

Though before we begin one ci/cd guideline we will try to follow

            Never Top-up on a failed stage unless fixing it

What this means is that never add more code to failed branch or deploy to a broken env unless done to fix it .

Lets assume that the sprint goal are the following features :-

  • feature A : api's getTask and getTasklist : dev1
  • feature B : admin api to delete all tasks : dev2
  • feature C : api getUser : dev3
  • feature D : admin api to edit user details : dev4
  • feature E : experimental feature : dev5

Now lets assume that the development starts on Branch A, so this becomes our integration branch where all individual features will integrate.

Before moving ahead lets understand the development cycle that will take place

  1. Developer branches out from Branch A to develop the feature and merges back in Branch A when done , lets call these branches feature branches .

  2. In terms of testing we will run 2 kinds of tests

  3. To deploy the application we will need to create an deployable artifact from

For the above scenario lets understand the test deliverables for first 2 features:

feature B depends on feature A (admin api to delete task will need to call the api to get the task list). Hence dev 1 delivers unit tests for getTask and getTaskList dev 2 delivers unit tests for admin api to delete all tasks which will mock the getTaskList Api. integration tests for the api will call the actual object of the getTaskList and mock the call for the authorization service

The following depicts the sequence of dev events that may take place.

In the above at point 2 we have feature A unit tested , feature B unit tested and Branch A is integration tested .

So Have we tested enough ? No, we will still need to test feature B for the external authorization service call When will that happen ? when we deploy the application onto SIT and test the application there .

At this point this story can progress in 2 ways :

Way 1 .

A artifact is created at point 2 in Branch A which is deployed to SIT for testing which fails !! The auth service call did not yield the result as the code expected .

So dev2 now gets on to fix this , Branch A meanwhile has progressed to Point 3 and hence he branches out from there and starts fixing the issue in bugfix B branch. As was agreed in the arch that auth service call will be done through an adapter class which others can use too so dev2 starts fixing that class .

Meanwhile dev4 is ready with the code changes for feature D and has unit tested it . He now needs to do integration testing of Branch A with his feature integrated and although he is affected by the external auth call issue , he should be allowed to merge the changes in Branch A as that doesn't involve testing the actual service and follows the above guideline

dev 2 is ready for the fix but , unfortunately Integration test fails for feature D on branch A . Now lets evaluate the situation :

We have :

  • feature A is tested completely and ready to be delivered to UAT
  • feature B is tested for integration and ready to be re-tested on SIT
  • feature C is tested and ready to be tested on SIT
  • feature D has failed integration
  • bugfix B ready to be merged .
  • SIT broken
  • Branch A broken

At this junction the maintainer has a couple of choices :

  1. Ignore the guideline and merge bugfix B to a broken Branch A to create an artifact to deploy to SIT : effort low : wait_time low
  2. Branch out from point 3 and create a new integration branch and merge the bugfix B to it and create artifact and deploy to SIT : effort medium : wait_time medium
  3. Ask dev 4 to undo the code he merged to branch B and merge and then continue : effort high : wait_time medium
  4. Wait for dev4 to fix the issue and merge to branch A and then continue : effort high : wait_time unknown

Notice that at the end of all the above choices we cannot guarantee a working SIT as there are other features which will be deployed to SIT with the fix for feature B and hence we cannot promise delivery

What if in choice 2 we branch out from point 2 instead of 3 .....

Way 2

At point 2 we create a new branch Branch B from which create the artifact and deploy that to SIT and testing fails. Fast forwarding to the point when feature D is integrated to Branch A and breaks it with only one change bugfix B would be now created from Branch B.

So compared to the above situation we now have just one addition to it .

  • Branch B with feature A and B