Client

طبقه بندی موضوعی

۲ مطلب در دی ۱۳۹۱ ثبت شده است

Export A MySQL Database

This example shows you how to export a database. It is a good idea to export your data often as a backup.
  1. Using SSH, execute the following command:
    mysqldump -p -u username database_name > dbname.sql 
    
  2. You will be prompted for a password, type in the password for the username and press Enter. Replace username, password and database_name with your MySQL username, password and database name.

The file dbname.sql now holds a backup of your database and is ready for download to your computer.

Import A MySQL Database

The file must be in .sql format. It can not be compressed in a .zip or .tar.gz file.
  1. Start by uploading the .sql file onto the Bluehost server
  2. If you haven't already done so, create the MySQL database via the cpanel. Click Here for further instructions
  3. Using SSH, navigate to the directory where your .sql file is.
  4. Next run this command:
     mysql -p -u username database_name < file.sql 

    Note: The -p will prompt for your account's password.

    Note: username is the user with rights to the database. If you are unsure what the username is you can use the same username and password used to sign into SSH.

    Note: Make sure your database name has your Bluehost username prefix with the _ (underscore) after it and the database name.

وقتی برای اولین بار یک سایت رو آنلاین میکنی مشکل چندانی نیست. میدونی که همه فایلها باید آپلود بشن و دیتابیس ساخته بشه و … منتها برای دفعات بعدی تقریبا عذاب آوره. اگر که دسترسی شل به سرورتون داشته باشید (مثلا vps باشه) یه راه خیلی ساده (با کمک git) میتونه به دادتون برسه.
من از git برای کنترل سورس استفاده میکنم. توصیه میکنم شما هم همین کار رو بکنید، git یا هر سیستم مشابهی. البته من تا مدتها از subversion استفاده میکردم ولی به نظرم git خیلی بهتر میتونه کارها رو راه بندازه.
پروژه مد نظر من با git مدیریت میشه. خوب برای اولین کار، من یک برنچ جدید توی این پروژه ایجاد میکنم :

git checkout -b published

این برنچ، قراره که منتشر بشه. یعنی هر چیزی تو این برنچ قرار بگیره، میخوام که روی سرور داشته باشم. توی سرور هم میرم و یک رپوی خالی میسازم. فرض کنیم توی پوشه root :

cd /root
mkdir project.git
cd project.git && git init --bare

یادتون باشه که این رپو یک جای کاملا private باید ساخته بشه، نه مثلا توی ریشه وب! فرض میکنم که من قراره برنامه رو توی /var/www منتشر کنم. یعنی وب سرور من از این پوشه به عنوان وب روت استفاده میکنه. حالا نیازمند یک اسکریپتم :

#!/bin/sh
TARGET=/var/www/
GIT_WORK_TREE=$TARGET git checkout -f published

خوب، اسم این اسکریپت رو میذارم post-recive و کپیش میکنم توی پوشه hooks توی project.git که توی سرور ساختم. دستور خط اول فقط برای راحتیه، که شما بتونید هر زمان که لازم بود عوضش کنید. دستور دوم میخواد به برنچ published سوییچ کنه، ولی اون GIT_WORK_TREE باعث میشه که این عمل سوییچ توی اون دایرکتوری مد نظر ما انجام بشه، نه توی دایرکتوری فعلی. مطمئن بشید که این اسکریپت اجراییه :

chmod a+x /root/project.git/hooks/post-recive

حالا وقت انتشاره :)
برگردید توی رپوی خودتون توی کامپیوتر خودتون. اول سرورتون رو به عنوان remote اضافه کنید :

git remote add server root@serveraddress:/root/project.git

گام بعدی هم انتشار واقعیه :

git push server published

من خیلی وقتا از سوییچ -f هم استفاده میکنم، این سرور، سرور اصلی git نیست، و من اصلا از سرور اصلی برای نگه داری کد استفاده نمیکنم. بنابراین اصلا حوصله ندارم درگیر merge و این مسخره بازیا بشم :) یعنی به محض اینکه گیر داد برای merge یا وقت rebase به مشکل برخوردم خیلی ساده :

git push server published -f 

تا اینجا خیلی ساده همه چی منتشر شد. ولی گاهی فقط همین نیست. بعدش هم گاهی لازمه یه سری کار انجام بشه. مثلا من میخوام شماره نسخه جدید برنامه هم به فرض توی فایل version.php کپی بشه.

من معمولا از خود git برای نسخه گذاری استفاده میکنم. برای نسخه گذاری، کافیه که یکبار یک tag به وجود بیارید :

git tag -a v1.1 -m"Version 1.1 of my project"

خوب اینطوری خیلی ساده نسخه ۱.۱ ایجاد میشه (من معمولا اینطوری نسخه میدم، مثلا v1.1 شما هر طوری دوست دارید نسخه بزنید، خیلی ها ترجیح میدن مثلا با تاریخ نسخه بزنن یا هر چیز دیگه‌ای. یادتون باشه که git خودش یه عدد سوم هم اضافه میکنه، بقیه نوشته رو بخونید)

خوب حالا تا وقتی کامیت جدید انجام نشده با دستور

git describe

همین چیزی رو که به عنوان tag معرفی کردید رو به عنوان نسخه بهتون نشون میده. ولی وقتی که کامیت کنید، تغییر میکنه به یه چیزی مثل این :

v1.1-2-gb69ac6a

قسمت اول که همون نسخه خود ماست. بعدش یه عدد ۲ اومده که نشون میده ما بعد از tag کردن دو تا کامیت انجام دادیم. بعد هم کامیت هش که خود git میسازه، و به نظر من خیلی هم بامزست ته نسخه باشه :)) ولی اگر دوستش ندارید خیلی راحت میتونید بعد از آخرین – همه چی رو حذف کنید (کار خاصی نداره، نه کاراکتر آخر رو حذف کنید فقط)
من میخوام اینو تو فایل version.php داشته باشم که یه فایلیه مثل این :

<?php
$version = "%%DEVELOPMENT%%";
echo $version;

البته منظورم یه ایده کلیه، وگرنه معمولا من این چیزها رو توی فایل تنظیمات که xml ـه اکثرا میذارم :)
خوب یه خط به آخر اسکریپتمون اضافه میکنم :

#!/bin/sh
TARGET=/var/www/
GIT_WORK_TREE=$TARGET git checkout -f published
sed -i s/%%DEVELOPMENT%%/`git describe`/g $TARGET/version.php

اما وقت push هم باید یه تغییر کوچیکی بدم، باید تگها رو هم push کنم :

git push server published --tags

البته همچنان حواستون باشه به سوییچ f و اگه لازم شد ازش استفاده کنید.
بازم هر کاری لازمه میتونید بعدش انجام بدید. مثلا یه دستور بذارید که کش رو پاک کنه، یا مثلا دیتابیس migration ها رو انجام بده و …باقیش دیگه بستگی داره به نیاز شما.

– سخت نیست اینکار رو برای svn هم انجام دادن. منتها اونجا قضیه یه کم متفاوته، که خوب، من نیازی بهش ندارم.
– برای tag کردن توصیه من اینه که حتما با gpg امضا کنید تگهاتون رو. به جای -a اگه بذارید -s خودش تگ رو امضا میکنه.
– git از نسخه ۱.۷.۹ به بعد امکان امضای کامیت ها رو هم با gpg میده. من که از اون موقع تا الان همه چی رو امضا میکنم :)))