Journey of your code from IDE to server in the production.
The magical leaps that you almost always ignore
If you’re a developer you would mostly work with a source code in some programming language like Java, javascript. You make source code changes, and push a commit. After some magical leaps in pipeline, the production server behaves the way you wrote in your source code. Let’s understand the journey of your code from your IDE to that server in the production.
In almost every software company, the software changes are released through a software delivery pipeline.
What’s a server?
There’s a machine (or a virtual machine) with an Operating System (OS) who runs an executable application which then serves the requests. The executable is generated from source code that developers writes.
How does your source code turns into executable?
The source code can be complied directly to an executable (machine code) or can be compiled to byte code (e.g. Java source code). If it’s an executable code then you can run it on a machine with that OS. If it’s byte code then you install another application on machine that can run the byte code (e.g. JVM for Java byte code).
Evolution of software release
Let’s say you are a only developer running a server, then your deployment cycle just looks like this
But what if there’s a team of developer who all are working in parallel, and only the latest changes should be copied to server. You can use git for that.
Good so far. What if the latest committed code has a bug? That bug is deployed to server. Server is now faulty. How can this be prevented? Instead of directly deploying to server, let’s deploy it to a testing server. We verify that latest changes are working as expected in testing (also known as staging) server before deploying to actual (production) server.
Who verifies that test server is working as expected? Well, QA testers can do that. But what if we are making lots of commits everyday, wouldn’t they get overwhelmed with testing again and again?
Solution to that problem is integration tests. Write automated tests that verifies end-to-end behavior of your server. “Verify the server is working as expected” would turn into “Verify that integration tests are passing”.
Compiling vs building
Usually you not only compile your source code but also have other scripts as part of getting your code ready for production. This may include compiling test code, running unit tests, verifying code coverage and checking code structure.
The build output also depends on what kind of server you have. If your server is a virtual machine then you need to build executable and copy it to server’s machine. If your server is running as docker container, then you need to build a docker image, then you need to restart the container with new docker image.
Putting it all together
If you found this guide helpful and want to stay updated on more tips and insights into software development, don’t forget to follow me on Twitter and LinkedIn.
Clap, follow, and let’s connect!
