Roles and Responsibilities

Sponsor

The 'Sponsor' is the owner of the external web project — usually a Department or Faculty representative.

Sponsors are responsible for development and maintenance of special websites through standard ÎÛÎÛ²ÝÝ®ÊÓƵ contracts, and for ensuring that guidelines are respected by devs and documentation (functional requirements user stories, technical specs) is included as part of the contract. Also, sponsors must define, review and test functionality.

It's the Sponsor's responsibility to have that document the features and objectives of the software in the event that another developer(s) takes over the project.

Third party developers and project team

Third party developers are responsible for providing code that follows published guidelines. They are contractually responsible for adhering to the guidelines and for any costs associated with making changes if they don’t follow the guidelines.

WSG

WSG is responsible for code reviews, systematically reviewing for security and coding standards. WSG does not carry out any development work on external projects; this means that we do not investigate, modify, remove, or create code for external projects, including upgrades/migrations to new versions of the WMS.

ÎÛÎÛ²ÝÝ®ÊÓƵ ITS

ÎÛÎÛ²ÝÝ®ÊÓƵ ITS provides the infrastructure and access so developers can perform their work. Please submit a ticket through ÎÛÎÛ²ÝÝ®ÊÓƵ Service desk for the fastest response, You may contact them at 514.398.3398 or visit /it/get-started-it

Procurement

Procurement provides the contract to be used with standard clauses for ÎÛÎÛ²ÝÝ®ÊÓƵ IT external web development.

First Steps

Remote Application Server (RAS) Access

If you have already submitted your ssh keys, and your ÎÛÎÛ²ÝÝ®ÊÓƵ Sponsor has requested a development environment you can check if your Remote Application Server (RAS) site is available by visiting $my-site (e.g. ). You will log into your new Drupal site with ÎÛÎÛ²ÝÝ®ÊÓƵ credentials, that will be provided to you by your ÎÛÎÛ²ÝÝ®ÊÓƵ Sponsor.

Sponsors can add you to the ‘RAS Active Directory group’ by submitting a request via RAS site provisioning and access request form

RAS sites cannot be provisioned without the following items already in place:

1. A signed standard ÎÛÎÛ²ÝÝ®ÊÓƵ IT Services contract between the RAS site sponsor and the vendor.
2. A signed Statement of Work describing deliverables that will be created using the RAS site that has been reviewed by IT Services staff to ensure that it meets WMS Development Guidelines.
3. A live WMS Drupal 7 site to associate the requested RAS site.

Connecting with VPN

If you are working from outside ÎÛÎÛ²ÝÝ®ÊÓƵ Central IT you will need to use a VPN connection to connect to your git repository. Your VPN connection must be associated with a static IP.

All Developers must download and install Cisco AnyConnect at the 
After installing the VPN client, you should immediately verify access by:

1. Connecting to securevpn.mcgill.ca/vendor
2. Logging in with your ÎÛÎÛ²ÝÝ®ÊÓƵ Resource Account and Password
3. Verify their access to the git repository

The Repository and Git

Once you have all your credentials, you will be able clone a GIT repository to your local machine for development — you are using git right?

You can view all repos you have access to using
ssh git [at] git.it.mcgill.ca

And here’s the command to clone a repository:
git clone git [at] git.it.mcgill.ca:repos/units/ccs/ras/$my-site
(e.g. git clone git [at] git.it.mcgill.ca:repos/units/ccs/ras/applying )

That command creates a directory named ‘applying’.

After a successful clone of the repository, you should create feature or hotfix branches that make sense for your development. Branch names should be short but descriptive enough to illustrate what the branch contains. When you're ready to test this code on the RAS you can merge it to the master branch and push it up to the git server. This will automatically update your RAS site with the new code. When you're ready for a branch to be made live, it should be submitted for code review, with deployment instructions. WSG staff will review the changes in that branch. Once you have requested and passed a code review, you may request deployment. More information can be found in our external development guidelines.

Git Resource:

Rules of the RAS

The Remote Application Server provides external developers an opportunity to quality assurance test libraries, drupal modules, custom modules against an always up-to-date version of ÎÛÎÛ²ÝÝ®ÊÓƵ’s internal codebase. Site content can be refreshed from the production site (or a staging site if it exists) via admin/structure/ras_reset

• As a developer you can login to your RAS Drupal site with full permissions, you are now responsible for the functioning of your RAS Drupal site.
• If your code/application does not work on the RAS it will not work in production - We can’t emphasize this enough.
• All RAS sites must correspond to existing or forthcoming Drupal 7 production sites.

You may need to know

• Update.php runs automatically on the RAS site when you push a commit to the Git server
• Channels content types can’t be saved because categories are currently not available via channels web service.
• Developers should commit /modules and /libraries at the root of the repository. Given that ÎÛÎÛ²ÝÝ®ÊÓƵ uses multisite, all development should be done assuming the repository code will be located in sites/mysite rather than the sites/all folder.
• A file named local.settings.php located at the root of the repository allows you to customize the contents of settings.php. You may use this file to override any variable defined in ÎÛÎÛ²ÝÝ®ÊÓƵ features, for instance $conf['theme_default'].
• The RAS server uses PHP 7, and uses an opcode cache which only checks once every 30 seconds to see if any PHP files have been changed. You may notice a brief delay after pushing new code before changes take effect.
• If you have any question, feel free to ask in our IRC channel #mcgill_web_external on freenode, or contact the service desk at 514.398.3398 or via /it/node/27784/need-help