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.
Summary
This lesson explains the conventional software development lifecycle before modern CI/CD methodologies. Multiple development teams work on separate branches of code in parallel—frontend, backend, database—using version control platforms like GitHub, GitLab, or Bitbucket. The traditional workflow progresses sequentially from development to testing, staging, quality assurance, bug fixes, and finally production deployment, with entire iterations lasting weeks or months.
Key points
- Multiple teams work in parallel on different code branches to isolate changes and prevent conflicts
- Version control platforms (GitHub, GitLab, Bitbucket) are essential for managing code from multiple developers
- The conventional approach follows a linear pipeline: development → testing environment → QA testing → bug fixes → production deployment
- Quality assurance teams test the software against original specifications and return bugs to development teams for correction
- The full iteration cycle—from development start to production release—can take weeks or months, creating inefficiencies
- This time-consuming, sequential approach motivates the need for modern methodologies discussed in the next lesson
FAQ
How do multiple developers work on the same project without losing code?
Developers work on separate branches in version control platforms (GitHub, GitLab, Bitbucket), keeping their code isolated and parallel. Each team member works on their own feature (payments, menus, database, etc.) and eventually merges code to the main branch when their work is complete.
What happens when testing discovers bugs in the code?
Quality assurance teams report bugs back to the development teams who must fix them. This requires repeating the entire development and testing cycle until all issues are resolved before the code can be deployed to production.
Why is this conventional approach considered time-consuming?
Because the entire process is sequential—development must finish before testing begins, testing must finish before operations deployment, and any bugs found send code back to developers to restart the cycle. Complete iterations from development to production can take weeks or months.