The Road To Production : How code gets into the hand of end user?

6 min readOct 16, 2023

but it works on my machine…

As a developer our main goal is to develop new things and to make sure they get available to the end user in smallest possible time and with highest quality.

When a developer is new they often not worry a lot about how the code is getting shipped to the end user, and the focus mainly remains to develop the user stories test on local and move on to the next.

If you get eager to learn about how things are getting deployed to end user’s devices, great you’ll make a difference and that’s where you get one step ahead of all the other developers who are not worries to know about it.

Lets start the journey and break it down into steps:

Plan
Development
Build and Deploy
Testing
Release

We can further divide them into more smaller steps and we’ll see that in each of the step.

1. Plan

This is the most initial phase of the requirement gathering, and to know what’s the real requirement to be developed.

The role of the “Product Owner (PO)” and “Business Analyst (BA)” comes into picture, often or not “Tech Leads (TLs)” are also involved in the discussion to make sure technical feasibility of the requirement.

This group comes together and finalise the requirement and then break them into smaller peaces which are also called “User Stories”. The user stories might be tagged to a bigger picture called “Epic”.

For doing this organisation use tools like “Jira” or “Trello” sometimes “Github Boards”

Once the user stories are created, this means business knows what do develop and what are their priorities, based on that the next phase comes which is “Development”.

2. Development

Developers choose what they want to work on from the Jira / Trello Board based on priority and their interest,

The process of picking cards / stories is called “Stroy Kick-Off” where 3-Amigos sit together and re discuss the card and resolve any doubt anyone has regarding the card / requirement / acceptance criteria / approach or anything once everything is clarified developer / developer pair picks the card and start the actual coding part.

Once they are done writing code and test cases and do a basic testing on their local machine and push the code to their version control which is often Github or Bitbucket, some basic pre-commit / builds runs and verifies if it is good to push.

version control tools, you can choose to focus just on github and bitbucket / gitlab because that’s what used by most of organisations.

This ends the development phase and now the code has left developers brain and machine, and can be in the first phase of deployment.

3. Build and Deploy

That’s the phase where fancy terms like CI/CD and Build Pipelines comes into picture, various tools like — GoCD, Jenkins, Github Actions, Gitlab Actions and more are used for it.

Once the code is pushed to version control pipelines gets a trigger, the assigned jobs runs one by one and notification gets updated if they pass or fail with logs, some basic things which it runs is — Build, Unit Tests + Code Coverage, Integration Tests, Contract Tests, and Deploy to lower (non-prod) and upper (prod) environments.

Applications are now a days wrapped into docker containers and shipped to registry, so it works on my machine problem ends and also because it’s lightweight.

After building the build it also needs to publish the artifacts which are generated, for this tools like nexus comes in use, and to deploy container docker and docker register comes handy.

Docker helps you to ship your application but then you work with micro-service architecture and may need to communication with many other services and at times you might also need to scale up and down based on uses,

so to do all of these orchestrators comes in picture a very famous example of it is “kubernetes” also known as “k8”, it’s a topic in itself so I’m not going to discuss this here, just assume it has some great powers and if used well it can allow your organisation to scale really well.

k8 also allows you to create namespaces using which you can differentiate between a non-prod environment and production environment, so you test your application really well on non-prod environment before shipping it to production.

4. Testing

Now you’re at a stage where you’ve deployed your application to any non-production environment lets say “dev” environment, you can now run your manual and automated integration tests, performance tests and see if the application behaves in a manner you want it to behave in production environment,

All the supporting tools like — Db, cache, messaging etc also should have lower environment so you can test them all together,

Typically organisation keeps 3–4 environment for different purposes,

like — UAT Environment, Beta Testing Environment etc, depending on application’s need.

Once the testing is done properly it’s ready to go to end user which means to be released.

5. Release

Finger crossed all the testing and efforts you’ve done is now going to make actual sense because it’s going to be available now to the end user and they are going to use it, and most importantly your business is going to hopefully make money.

This release in most cases should be automated and one trigger or one step should do it,

Now time for production bugs to come, because they will come no matter how many levels of testing you’ve done, that’s the truth :) you want to make sure nothing major blocker has gone into prod without you knowing it.

And that’s all :) you’ve made it to production.

Is it end of the journey??

No it’s a cycle, it will keep happening till the application is alive.

How do we find and debug bugs and Issues on Production.

One always have to provide production support for the product they’ve build, because if users are using it issues are meant to be come today or day after what matters is how you deal with them and proactively monitor.

There are different tools which are in market to do so, I can talk about it in next article but lets see the names