Code Collaboration, Testing, Releases And Support On Enterprise Projects

Enterprise-level application development process overview

  1. How do enterprise-level software projects start?
  2. How do enterprise-level applications development processes work?
  3. Code collaboration, testing, releases and support on enterprise projects

Code collaboration, testing, releases, and support on enterprise projects

Usually, developers take one by one task in progress then creates a pull/merge request to the development branch for another team member to check the accuracy, prevent bugs and find gaps. After fixes to the pull request, it may be merged. Another way is to create a branch for a feature that is usually mapped to the user story where multiple related tasks will be merged in then it may be tested and merged to the development branch. Both scenarios have advantages and disadvantages on the surface of parallel work, merge conflicts, and testing.

Nowadays the main source control is Git and the main workflow to handle branching strategy is GitFlow.

There may be different strategies for testers to test new changes and prevent regression, which depends on the system complexity, cross squads communication, and team decisions. One way is prior to merging the pull request, the branch may be deployed to the test environment to make an isolated test for new features. Another way is to test changes after the merge along with other merged features directly in the development branch which should be deployed to the test environment.

Once branches with required features merged to the development branch this version may be taken on a staging environment to do a full testing round for all deployed features. Then found issues should be triaged to get a common understanding of whether those are bugs or features and fixed. Also, the team needs to make sure those fixes are merged back to the development branch for not to lose them since the development branch will override other branches later.

CI/CD takes an essential role in nowadays development of big applications. Continuous integration (CI) and continuous delivery (CD) is an approach, collection of practices, and set of operating principles that make application development teams reliably and frequently deliver code changes.

Each merge/pull request should trigger the CI/CD pipeline where should be performed all automated checks like compilation and packages or containers creation, unit tests, integration tests, automated UI tests, code quality analyzers, deployments to test servers, migrations, and more. In some teams, I saw partial CI checks for every commit. This is pretty expensive to run a full CI/CD pipeline for each commit to the repository, since it may last from minutes to hours depending on the system size and setups.

One thing I saw not so often as I want, is the build promotion to the environments without rebuilding if it passes all checks. This approach helps minimize load on build machines and eliminate dependencies on temporary resources and fantom compilation errors.

Once atomic system parts are developed or the system upgraded with new features they may be released. There may be multiple release strategies: one big bang, frequent releases or each merge to the develop branch may trigger a deployment to production, it depends on the system complexity, load, cloud providers, geo-replication, team readiness.

As you see, there are many roles involved in big projects. I still did not mention a scrum master who tries to make team follow best agile practices, a project manager who makes sure everything goes on time and team members are satisfied. Also for each squad should be team leaders who are responsible for distributing load accurately across squad members, ensure code review goes in the right way, take leadership in most challenging questions within the squad, assign mentors for junior colleagues, and more.

Once the project is fully developed and released there should be a team assigned to support the production environment and fix new or known issues.

At this point, the business can cut the budget for the development team unless they have already prepared a new roadmap for the development of new subsystems or upgrading existing ones.