Development Cycle

I could suggest the development cycle given below. This is not a “be-all and end-all” example and can be altered based on your needs.

asdfsdf

(Optional steps contain dashed lines)

Create a Development Environment for The Task

I could suggest you to create a development environment for each task. It would be very good practice to name the development environment based on a ticket name if you have such practice in place. Say you have a ticket named PT41 - Remove print statements for Python 3 compatibility. The ideal name of a development environment for it would be PT41 and its path would look like;

/<PATH>/meco/<PROJECT_NAME>/developers/<DEVELOPER_NAME>/development/PT41

Create or Clone Packages

Create or clone the packages required for the task.

Test Driven Development

I suggest you to take advantage of TDD, if you haven’t already since it would benefit your team a lot.

Run Package Release Pre-Dependencies

You can run package release pre-dependencies by invoking mmecorelease-check and mmecorelease-check-all to ensure that the packages you work on are production ready based on outlined requirements of your pipeline.

Code Review (Optional)

I put two code reviews in different steps in the diagram above. Software teams conduct code reviews in different steps where they see it fits. You should find the best step, at what point you should conduct code review based on your development practices and requirements.

Pushing your Changes

You can push your changes to remote repo after making sure that all unit tests passed, and the packages themselves are ready for deployment.

CI (Optional)

If you have CI in place, pushing your changes to repo would trigger the tests you implemented as well. If a failure occurs in this step you could go back to TDD step to fix the issues.

Creating a Stage Environment (Optional)

If the changes you made require to be tested by other developers or by you manager, you can allow them to do so by creating a stage environment where they can initialize the stage environment and test your changes. If you receive requests for changes to be made you can go back to TDD step.

Merging your Branch

When you hit this point you can merge your branch into the relevant one in use, which usually be master branch.

Package Release

All we have to do is to release our package(s) since the development cycle itself is completed successfully. We can do so by invoking either mmecorelease-release or mmecorelease-release-all command based on given circumstance.