Single source of documentation for the University of Alberta Libraries developers common tools and practices
Version control is important to our operation
- integration with other developers work
- manages change history
- can revert working copy to a previous working state
- tag releases
- backup
Github https://github.com/ualbertalib
Ops managed Github https://code.library.ualberta.ca/gitweb/ -- requires Network login / Windows credentials
The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. [The Secure Shell (SSH) Protocol Architecture]
The recommended way to authenticate and communicate over ssh is through public/private key pairs. You share your public key with a server and it is stored in .ssh/authorized_keys. Keep your private key secret and on your desktop machine (in your ~/.ssh/ directory).
These keys can be created with Linux command-line tools. In a Windows environment, they can be created using the equivalent tools in [Cygwin]. If you have already created a key pair with PuttyGen and shared it with the sysadmins, you can convert it to the necessary OpenSSH-style keys by following these instructions.
To create your keys:
ssh-keygen -t rsa
They are located
ls ~/.ssh
id_rsa id_rsa.pub
To use these as credentials:
- share your public key (id_rsa.pub) with your friendly neighborhood systems administrator
- before attempting to login for the first time in a session, you must start the ssh agent and add your key (hint add this to your bash profile):
eval `ssh-agent -s`
ssh-add
- to see which keys are currently loaded
ssh-add -l
In Windows you can [use Pageant] to load your key for use by Putty.
DevOps means different things to different people. To us it means Developers and Operations working together (Dev+Ops=DevOps) towards the same goal of putting quality applications in production as efficiently and painlessly as possible.
Once an application is 'working' it is deployed in dev, test, and prod environments. This facilitates the hand off between the Developer and Operations, by giving the Developer a production-like environment to build in, a test environment for developers and Operations to collaborate and practice on, and a production environment that is a known quantity to Operations because it's been proven.
- developers have sudo privileges
- some software probably installed from version control
- if depends on services like MySQL, these probably exist on the same machine
- working towards headless installation/configuration using configuration management software
- may be 'golden' vm on Developer desktop or vm provided by Operations for this purpose
- no backups!
- developers may have sudo privileges
- provisioned using Docker Images
- may point to services (like MySQL) on external test server
- primary purpose is to provide a platform to demo to stakeholders for acceptance and performance
- developers do not have sudo privileges
- software installed from RPM
- installed using configuration management software
- Writing and running Ansible playbooks is the recommended practice for deployment of applications.
- point to services (like MySQL) on external production server (with backups and security)
When a bug or feature is identified which requires a change.
- Identify which component(s) are affected.
- Write test which identifies bug.
- Write code which fixes bug.
- Tests pass.
- Update documentation
- Commit to version control. (Everything is in version control!)
- Build component
- this varies depending on component affected
- ks requires rebuild of server
- package requires rebuild of package
- last mile script/recipe doesn't really require this step
- Deploy/update component in 'test' environment
- Tests pass
- Change request for anything big (in accordance with ITIL principles)
- Deploy/update component in 'prod' environment