![]() It’s also a good way to be sure your app build didn’t fail. It allows everyone to iterate and make feedbacks before the code lands on the master branch. Having a staging environment for all open PR allows devs, PO, PM and scrum masters to play with this exact version of the code (on any browser they want), and really see if the bug is fixed, or if the feature correspond to the PO needs. It was not the simplest thing to do on our web project, but this is probably one of the most useful feature we have on our stack. The « Preview step » is more interesting. We already use Jest and ESLint, but we have to dig more for Integration test ( Appium ?). ![]() The « Test step » is related to React Native. The « Branch step », « PR step » and « Code Review step » are mostly related to our CVS (Github Enterprise) and are not a problem. Preview : an internal tool (Github Hooker) is called with a Github webhook on each PR to create a staging environment.Test : a CI system ( Jenkins) runs Unit and Integration tests, and Lint on each PR,. ![]() Code Review : other teammates have to review each PR and add :+1: when they agree with the modification,.Pull Request (PR) : we make PR for each bugfix or feature to propose the modification to the « master » git branch,.Branch : every bugfix or feature is developed on a new git branch,.Here is the workflow we use for web development: We are playing since a few weeks with React Native for a Proof Of Concept and wanted to have the same development workflow for mobile apps, as we have for the web. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |