Abstract

How we manage and use DevOps in our startup MVP

DevOps is familiar to both startup companies and mature enterprises. Many people say, “MVP is about rapid development and quick validation” aiming to develop a functional product as quickly as possible (sometimes even using No-code tools?!). Initially, I thought the same way: one or two cloud servers could handle all the deployments (one for Staging/QA, one for Production). However, as the projects and products grew (from DEV to MVP), the security of microservices and the efficiency of development/deployment faced numerous challenges. This is why I’m writing this blog post—to share the current DevOps architecture for our MVP product.

OriginTechX.inc architecture diagram

Services & programs we used

1. Github Organization
   • Github Action (Continuous integration)
   • Github Packages (Image repository)
2. Docker (Build image & deploy to staging/QA environment)
3. kustomize
4. ArgoCD
5. Kubernetes

---

Step Description

DEV→QA

Developers work on their own dev branches for local development, then commit a PR to the Staging/QA branch, triggering the Build-test and Build-image actions. The branch label is automatically retrieved, and the packaged image is stored in GitHub Packages. After completing the Build-test and Build-image steps, the application is automatically deployed to the Staging/QA host. Once the deployment is finished, the QA tester can perform internal testing.

Staging → Production(CI)

The testing team completes the necessary test items and determines the release date for the next version. If there are any hotfixes during this period, bugs can be fixed immediately. Finally, a Pull Request is created and merged into the main branch. In our actions, we use semantic versioning, so when a PR is initiated, the Git version is automatically retrieved, a tag is applied, and the release is published to the release packages.

Staging → Production(CD)

In Continuous Deployment for production, we use Kustomize to render YAML files. During the previous stage when packaging the image, we pull the SHA256 and use “yq” to replace the image SHA256 in the Kustomize-rendered deployment.yaml. Finally, we enable ArgoCD’s automatic deployment function to achieve continuous deployment.

# kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: monitor

configurations:
  # Dynamic service name
  # Tie target Service metadata.name to IngressRoute's spec.routes.services.name
  # Once Service name is changed, the IngressRoute referrerd service name will be changed as well.
  # https://stackoverflow.com/questions/71704023/how-to-use-kustomize-to-configure-traefik-2-x-ingressroute-metadata-name-spec
  - nameReference.yaml

labels: # All resource print label
  - pairs:
      variant: monitor
      owner: origintechx
      app: otx-prometheus
    includeSelectors: false
    
resources:
- xxxx
- xxxx
- xxxx

# nameReference.yaml
nameReference:
  - kind: Service
    fieldSpecs:
      - kind: IngressRoute
        path: spec/routes/services/name
  - kind: Middleware
    fieldSpecs:
      - kind: IngressRoute
        path: spec/routes/middlewares/name
  - kind: Secret
    fieldSpecs:
      - kind: Middleware
        path: spec/basicAuth/secret

ArgoCD thumbnail

Conclusion

After implementing DevOps, it allows the development team to focus more on development. As long as the startup’s rules are clearly defined, even new developers can quickly get up to speed. However, the founders still prioritize the market and the product.

- Founder Frank