You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org
Help:Development recommendations for easily moving to production
<inputbox> type=fulltext prefix="Help:Tool" searchbuttonlabel= Search placeholder=Search Toolforge Documentation width=35 break=no </inputbox>
This page describes processes for advanced users, specifically individuals who are developing services aimed at Wikimedia production.
Avoid pip, pecl, gems, and other language specific package managers
Please, take care when using language specific repositories, like pip, pecl, etc. In production we do not use language specific package managers because they generally do not provide cryptographic end-to-end trust guarantees for the software they install.
When pushing to production, all dependencies must:
- Be installable as Debian packages
- From the official Debian repository or Wikimedia hosted apt repositories
If a package isn't available in the official Debian repository can be packaged and hosted in a custom Wikimedia repository.
Language specific package managers
When using language specific repositories, newer versions of libraries than are available in the Debian repository may be installed. Your application may then depend on the newer versions, and when we puppetize the system, the newer versions have to be backported to whichever distro version we are using.
We recommend that before using a language specific package manager, you check to see if the required library exists in the Debian repository first. Unless the packaged version is too old, please use it rather than the version in the language specific package manager. When using a language specific package manager, please document the library that was installed, so that it can be packaged when the service is puppetized and deployed to production.
Document all package installations, all modified configuration files, and any commands run to configure a service
Documenting how a service is installed and configured makes the puppetization of a service much easier. It should be possible to fully puppetize a system just by reading the documentation. This also means that when a service is changed after being deployed to production that its documentation should be updated as well.
Know and document any ports and protocols in use by your service
It's important to know which ports and protocols are in use by your service, and how that affects the security of a service. Memcache, for instance, runs on 11211, and by default has no security. It's important to firewall the service, or to ensure it isn't accessible to the public. Many services have considerations like this, and documenting these makes them much easier to puppetize.
Communication and support
We communicate and provide support through several primary channels. Please reach out with questions and to join the conversation.
|Phabricator Workboard||#Cloud-Services||Task tracking and bug reporting|
|IRC Channel||#wikimedia-cloud connect
|General discussion and support|
|Mailing List||cloud@||Information about ongoing initiatives, general discussion and support|
|Announcement emails||cloud-announce@||Information about critical changes (all messages mirrored to cloud@)|
|News wiki page||News||Information about major near-term plans|
|Cloud Services Blog||Clouds & Unicorns||Learning more details about some of our work|
|Wikimedia Technical Blog||techblog.wikimedia.org||News and stories from the Wikimedia technical movement|