Gitlab 1-4 conventional approach without the following method

In this lesson we look at how applications used to be developed before the CI/CD methodology. We are picking up the SDLC where we left it — past the requirements, definition and design stages — and entering the build phase. The focus is on the development side of things, not deeply on design.

Multiple siloed teams with their own branches

For a large project, development is typically split into multiple teams, each with a clear role: a frontend team, a backend team, and so on. Each team has its source code stored in Git. We assume you already know Git: a free, open-source tool to track project changes over time. Multiple platforms on the market expose Git remotely — GitLab, GitHub or Bitbucket.

Because many teams work in parallel, the code is kept separated and isolated using several branches. For example, one developer may work on the payment module, two others on the menu, others on the database, etc. Each developer commits to their own branch and tests there in isolation. In the worst case — which is rare today — code is even kept only on a local machine.

Manual hand-offs slow everything down

When some phases of code are complete, they have to be merged together to obtain a single, unified branch — typically master. The integrated code is then handed off to a build team. Once their work is done, it is forwarded to an operations team responsible for deployment, who also writes the necessary configuration and installation instructions for the application.

The ops team first deploys to a test environment, where the QA team runs quality and acceptance tests. If bugs or missing requirements are found — which is almost always the case — the issues are sent back to the development team. Developers fix the bugs, and all previous phases repeat: build, hand-off, test. Once the code passes QA, the ops team deploys to production: the application becomes available on its market (App Store, Google Play, etc.).

When a new update is needed, the entire cycle starts over. The full loop is called an iteration, and it can last weeks or even months. That is roughly how software was developed before the CI/CD methodology arrived: slow, manual, exhausting on the long run for the people involved. In the next video, we will see why the industry moved to a more modern approach and what CI/CD changed concretely. Thanks for watching.