Step 31: Don’t Touch that Code! ~ Cal Evans

Birat Rai
2 min readNov 6, 2017

--

This is the 31st Step towards gaining the Programming Enlightenment series. If you didn’t learn the 30th Step, read it.

What is Software Release Management?

Release management is the process of managing, planning, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases.

What is Continuous Deployment?

Every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day.

What is Continuous Delivery?

Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time. With Continuous delivery we can do frequent Continuous Deployment.

What is the benefits of Release Management, Continuous Deployment and Continuous Deliver?

  • Reduced Deployment Risk: since you are deploying smaller changes, there’s less to go wrong and it’s easier to fix should a problem appear.
  • Believable Progress: many folks track progress by tracking work done. If “done” means “developers declare it to be done” that’s much less believable than if it’s deployed into a production (or production-like) environment.
  • User Feedback: the biggest risk to any software effort is that you end up building something that isn’t useful. The earlier and more frequently you get working software in front of real users, the quicker you get feedback to find out how valuable it really is (particularly if you use ObservedRequirements).

What is a typical Release Management?

We follow a series of steps, before we roll out for production.

  • Local development and unit testing on the developer’s machine
  • Development server where manual or automated integration testing is done
  • Staging server where the QA team and the users do acceptance testing
  • Production serve

When to fix the problem?

As a developer, we test and work the software in a development environment, on developer’s local machine with local settings. Once we follow the approach of release management, QA engineers test it in production environment and if all well release into production.

We have seen the benefits of the release management, so what happens when we face a critical bug in production, how do we fix that. With our model of software release, no any developer should access the code beyond the development server.

Under no circumstances — ever, at all — should a developer have access to production server. If there is a problem, that should come as a patch, like another roll out.

TL;DR If it’s broke, production is not the place to fix it.

Go to the series.

Go to 30th Step

Go to the 32nd Step.

References:

--

--

Birat Rai
Birat Rai

No responses yet