Resources on SDL: Software Development Labhttps://sdl-56e997.gitlab.io/resources/Recent content in Resources on SDL: Software Development LabHugoen-us<link>https://sdl-56e997.gitlab.io/resources/best-practices/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://sdl-56e997.gitlab.io/resources/best-practices/</guid><description><h1 id="best-practices-for-sdl">Best Practices for <a href="./">SDL</a></h1> <p>Teams should adhere to the following practices, but may vary from them after consultation with the instructor:</p> <ul> <li>GitLab Configuration: <ul> <li>All students on each team should have Developer role. We can give them Maintainer role temporarily when required. Set the expiration date to July 1 or February 1, as appropriate.</li> <li>Disallow pushes to the main branch. This is ensured by going to <strong>Settings</strong>, <strong>Repository</strong>, <strong>Branch rules</strong>, <strong>view details</strong>, <strong>Manage in protected branches</strong>, and select <strong>No one</strong> for <strong>Allowed to push and merge</strong>. <strong>Allowed to merge</strong> will be set to <strong>Maintainers</strong> (or <strong>Maintainers + Developers</strong>).</li> <li>Disallow squash commits: <strong>Settings</strong>, <strong>Merge requests</strong>, scroll down to <strong>Squash commits when merging</strong>, set to <strong>Do not allow</strong>. Save the changes.</li> </ul> </li> <li>Git standards (for all repositories): <ul> <li> <p>Configure your git setup so check-ins and check-outs are <strong>as-is</strong>. This means git will <em>not</em> convert line endings between Unix/Window/Mac formats. The conversions are not needed since all modern editors can handle different formats. Allowing git often breaks deployment. You can set this by editing your <code>.gitconfig</code> file to include the text</p></description></item><item><title/><link>https://sdl-56e997.gitlab.io/resources/ci/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://sdl-56e997.gitlab.io/resources/ci/</guid><description><p>Use this <code>.gitlab-ci.yml</code> as a starting point for your CI system:</p> <pre tabindex="0"><code>image: docker:latest services: - docker:dind stages: - build build: stage: build script: - docker build . </code></pre><p>The first line says you are using the latest version of Docker; once things are working, specify the version for extra robustness. The <code>build</code> entry specifies how to do the build, which is just executing the <code>docker build .</code> command you are used to using in Ubuntu. The <code>stages</code> entry just specifies doing the <code>build</code> stage; one could add additional stages for things like continuous delivery or to build multiple versions of your project.</p></description></item><item><title/><link>https://sdl-56e997.gitlab.io/resources/ubuntu-with-virtual-box/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://sdl-56e997.gitlab.io/resources/ubuntu-with-virtual-box/</guid><description><h2 id="configuring-virtualbox-with-ubuntu">Configuring VirtualBox with Ubuntu</h2> <h3 id="if-useful-also-covers-using-docker">(If useful, also covers using Docker)</h3> <p>This will enable teams to develop on Linux on their laptops, avoiding problems with connecting to services over a network. Many teams will stage their system on a remote server, but enabling local access</p></description></item></channel></rss>