Skip to content

ContributingDeploying

peder2911 edited this page Aug 11, 2021 · 1 revision

Contributing and Deploying

You are doing this tutorial to learn the skills necessary to be able to contribute to ViEWS. This section teaches you how contributions should be made, and how you deploy new versions of the services to our web server.

Our infrastructure might change in the future, but the general principles taught here will be applicable no matter what machines end up running what services. If anything, deployment will become simpler and more streamlined, with more automation in the build-step: Images might be set up to build automatically whenever commits are pushed to the master branch. This would eliminate the build step.

Please complete the "Running Locally" section before doing this one.

Task 1 contributing code via Git:

As mentioned previously, each service is associated with a separate code repository, contained in a metarepository called views3. Code changes to each service is contributed to each service's Git repository like you would contribute to any other repository.

Git has many possible workflows, but the one chosen for ViEWS 3 is the feature branch workflow. This workflow mandates that code should not be pushed directly to master, but should instead be organized in feature branches, with one branch per new feature. Being a small team, we can allow ourselves some leeway in terms of how strictly we should follow this workflow, but one should keep in mind that it is designed to make code collaboration easier, avoiding some of the code merging pitfalls involved in trying to work on the same branch (by reducing the number of point-merges you have to do).

Working in a branch, you can work incrementally by changing code and rebuilding services locally (see the Running Locally section). This way, you can try out new functionality in a local environment where you don't have to worry about breaking anything. By pushing your changes to Github in a branch, others can try out your code as well, verifying that it works.

Once you've made changes constituting a feature (this distinction is not very strict), submit a pull-request on Github to merge your changes into the master branch.