Deployment, Continuous Integration, Software Quality Assurance — Deployment
Hi everyone! In this blog post, I want to explain to you all about my understanding and implementation of deployment in the software development of Moodah POS (Point of Sale) system for the Software Engineering Project.
What is Deployment in Software Development?
In software development, deployment is all of the activities that make a software system available for use. While the term deployment always involves changing the state of software from being in development to being at least mostly completed, deployment can mean different things depending on the type of software. For example, in the context of web development, deployment does not mean being released to the public. Rather, it means moving the software to a server where it is placed into action. This can be done prior to final testing before a release to the public or the client for whom the software is being developed. In its strictest sense, software deployment refers to the release of the final version of software or an app to either a customer or the general public. This takes place at the end of the life cycle, but prior to the start of maintenance, which only takes place once software has been finalized and released for public use.
What is Software Environment?
In software deployment, an environment is a computer system in which a computer program or software component is deployed and executed. In simple cases, such as developing and immediately executing a program on the same machine, there may be a single environment. However, in web development, for example, there are more than a single environment.
Generally, there are 3 environments in web development, which are, development, staging, and production. Development environment is the environment on your computer. Here is where you will do all of your code updates. It is where all of your commits and branches live along with those of your other team members. Nothing you do in the development environment affects what users currently see when they pull up the website. This is just for you and the other team members to see how new features will work and to try out improvements. This environment is also meant to be used for internal code testing and usually, it will be used for unit testing. Staging environment is the environment where you will have all of the code inside a server instead of a local machine. It will be connected to as many services as it can without touching the production environment. All of the hardcore testing happens in this environment. Any database migrations will be tested here and so will any configuration changes. When you have to do major version updates, the staging environment helps you find and fix any issues that come up too. This is also the environment where you can give a demo to the client of how the website will work and look. They will be able to see how things will work when the website is live and they will be able to give you any feedback you need. Production environment is where users access the final code after all of the updates and testing. Of all the environments, this one is the most important. This is where companies make their money so you cannot have any crucial mistakes here. That is why you have to go through the other two environments with all of the testing first. Once you are in production environment, any bugs or errors that remain will be found by a user and you can only hope it is something minor.
How My Team Implement Deployment in Our Software Engineering Project
In Moodah POS Software Engineering Project, we used automated deployment. Automated deployment is a form of deployment where the defined steps for shipping code from a development environment to staging/production environment is a one-step procedure and fully or partially automated.
There are some benefits of using automated deployment scheme in the application, for example, deployment become much less error-prone and much more repeatable since automated deployment does not suffer from variability. Once configured, the process is set and will be the same every time a release is initiated. If it works the first time you deploy your software into a given environment, it will work the 100th time. The other benefit is that developers can get an early bug detection. If there is an error in the local version of the code that has not been checked, a build failure occurs at an early stage that easily notifies developers to make a fix.
Terminologies in the Automated Deployment
CI and the two CDs
Continuous Delivery is an approach to release new changes to customers quickly and reliably, it consists of implementing Continuous Integration and Continuous Deployment, or CI/CD for short.
Continuous Integration (CI) is the set of practices done by developers to merge their work to the main branch as often as possible. This often involves validating, building and running automated test against application with the added changes. Continuous Delivery (CD) is a method to deliver functionalities to customers through automated deployment.
Docker
For front-end deployment, we use Docker which is a platform for developers to run application through containerization. Containerization is a lightweight alternative to full machine virtualization that involves encapsulating an application in a container with its own operating environment. This provides many of the benefits of loading an application onto a virtual machine, as the application can be run on any suitable physical machine without any worries about dependencies. Containerization is increasingly popular because it is lightweight since it shares the kernel of the host machine, can be run on any environment and easily scalable.
Docker uses a Dockerfile that contains a list of dependency instructions on how to run an application to build an image. A Docker image includes everything needed to run an application such as the code, dependencies, and commands to execute when it is run. The running instance is called a container.
Our pipeline
The application is composed of a React-based application for front-end that is deployed using Docker to servers provided and a GraphQL Apollo server which is deployed to AWS Lambda. Both are hosted in a mono repo format on GitLab.
The first component of our automation starts with the GitLab’s job runner executing scripts written in gitlab-ci.yml file after triggered by a push to the repository. In this place, we run automated linting and tests to ensure errors are caught early to stop the changes from being deployed. For the front-end and back-end deployment, we have different routes.
Deployment in Front-End
For the front-end application, there are some stages as shown in snippet of gitlab-ci.ymlbelow.
The first job to do is to test the application and displaying its coverage. If all tests pass, then the runner will proceed to pull the most recent image as a cache, then it is uploaded to a docker registry, which is a docker-image-equivalent for git repository hosting like GitLab.
Docker uses theDockerfile to tell it how to run our react application.
Docker will build the react application to static files then serve it with nginx when the image is run.
The last step is to run the image in a server. In our Moodah POS project, we are provided with servers and portainer, which is a GUI for building and running docker images, to ease deployment using Docker. We need to add a new container from an image that we pushed to earlier in the CI script and run it.
It can already be accessed in https://itprojectkitwo-staging.cs.ui.ac.id.
Thank you for reading :)
