Week 9 — Deployment, Software Architecture, and User Profiles

Valentina Kania
println-mic
Published in
4 min readApr 3, 2018

So, between week 7 and week 9, what have I done?

Gitlab CI/CD Flow

Deployment — Software Environment

Software Environment is a term used to refer to an environment that supports a software, including operating system, database, specific tools or container, even hardware tools (if applicable, like a printer, for Println).

Last week, some of our first features were reviewed on Sprint Review with our Product Owner and the lecturers. If our features merged in SIT (System Integration Testing) UAT (User Acceptance Testing) environment are accepted, they would be deployed to production. There are three major environments in Println, staging (we also call them coba_coba), SIT UAT, and production.

What We Use

We are using CI/CD tools from Gitlab, configuring the scripts for test and deploy in a .gitlab-ci.yml file. We define our CI/CD environment variables in Gitlab Settings.

Staging Environment

A staging server is a mirror of the production business management server. — Microsoft Developer Network

Staging environment is an environment created to mimic production environment, used for testing purposes. In Println, staging environment is connected to every branch except sit_uat and master; meaning every story branch is connected to this environment.

Everytime someone pushes to a story branch, the CI/CD script will run two tests, called test_frontend and test_backend. If both tests pass, the script will run a deployment stage to the staging server.

Script for deploy_staging

SIT UAT Environment

SIT UAT environment, just as its name, is an environment for testing, System Integration Testing and User Acceptance Testing.

The first step, System Integration Testing, tests how our current feature works with the currently merged system, how it integrates with the others, and testing the system as a ‘whole’ (the current whole, not the real whole application). In this environment, we can detect if a feature is conflicting with another feature, if the product flow does not work as expected, etc.

User Acceptance Testing tests whether our users would be satisfied with our current product. For Println, our users are the stakeholders. This is why this SIT UAT environment is the environment exposed to the stakeholders in Sprint Review.

Production Environment

News flash: Our production server is currently moved again to Heroku.

Well, production environment is a real environment. It hosts the real working application of Println, contains the real database, and (ideally) interacts with the real target users of Println. Basically, it is published. That is why the process of deploying an application to this environment needs a long process and checking.

After we test our features in the SIT UAT environment, Println stakeholders, which consist of MIC representatives, lecturers, and the scrum team, meet together in what we call a Sprint Review, and have the available features tested. If our features are accepted without notes, or if the notes are already resolved, we can directly create a PR from sit_uat branch to master branch, where the CI/CD script will deploy our application to the production environment. In Println, only the Scrum Master has access of running the CI/CD job to production environment.

What Have I Done?

  • Creating endpoint for Edit Profile — I learn something, it is better to use ViewSets than APIView, how to create better Response format for our Frontend engineers
  • Writing API Documentation — again, to help our frontend engineers understand what our REST APIs are doing. We are currently writing in Markdown files, and we are planning to write in YAML in this sprint
  • Deployment, again and again — last week, our Heroku account got suspended due to concurrent build limit, so we need to move our server to a new account. Then, just last night, our Product Owner decided not to fund our production server anymore, so we needed to move the production server to a new, fast, and free one: Heroku.
  • ES6 — I wrote two teeny tiny functions in Javascript, to create a file validation system. And I learned a little about Enzyme, the testing library.

--

--