نوشته های آیدین نصراله پور

انتقال سرور gitea

آیدین نصراله پور — Thu, 19 Aug 2021 16:30:10 +0430

Gitea - Git with a cup of teatراحت ترین و بی دردسر ترین راه ایجاد git سرور شخصی، نصب gitea هست. از مزایای gitea میشه به سبک بودن، کراس پلت فرم بودن، نصب ساده و وجود افزونه gitea برای jenkins اشاره کرد. توی ویرگول چندین مقاله دیدم در رابطه با نصب gitea و به نظرم لازم نبود که برای نصب هم مطلب بنویسم(هر چند خیلی از مراحلی که توضیح میدم مشابهه).جیزی که قراره توی این مطلب توضیح بدم نحوه انتقال سرور gitea و مهاجرت داده های اون هست. البته این کار شاید خیلی متداول نباشه ولی خوب برای من پیش اومد و میخوام تجربشو با شما به اشتراک بذارم.پیش فرض ها :1.سرور مبدا و مقصد از سیستم عامل لینوکس ( cent os) استفاده میکنند.2.برای راه اندازی gitea از دیتابیس postgresql استفاده شده است.3. همه کارها رو با یوزر root انجام میدیم** از این به بعد به سرور مبدا A و به سرور مقصد B میگیم.**اول از همه باید B رو آماده انتقال کنیم. این مراحل مشابه مراحل نصب میباشد. پس از طریق ssh وارد B میشیم و مراحل پایین رو طی میکنیم.نصب بودن git روی B رو بررسی میکنیم :git --version۱-۱. در صورتی که git نصب نبود، نصبش میکنیم :yum install git۲. یک یوزر جدید به نام git برای اجرا کننده gitea ایجاد میکنیم useradd git passwd gitنکته ۱ : در صورتی که میخواهید اسم یوزری که اینجا تعریف کردید با یوزری که قبلا توی A داشتید متفاوت باشه پس از انجام مرحله ۳ انتقال، داخل فایل /etc/gitea/app.iniمقدار RUN_USER رو با username دلخواه جایگذاری کنید.۳. دایرکتوری های مورد نیاز رو ایجاد میکنیمmkdir -p /var/lib/gitea/{custom,data,log} chown -R git:git /var/lib/gitea/ chmod -R 750 /var/lib/gitea/ mkdir /etc/gitea chown root:git /etc/gitea chmod 770 /etc/gitea۴.داخل /opt یه فولدر به نام gitea ایجاد میکنیم و فایل باینری رو دانلود میکنیم و فایل رو قابل جرا میکنیم :cd /opt mkdir gitea cd gitea wget -O gitea https://dl.gitea.io/gitea/1.14.6/gitea-1.14.6-linux-amd64 chmod +x giteaو در نهایت باینری دانلود شده رو در مسیر زیر کپی میکنیمcp /opt/gitea/gitea /usr/local/bin/gitea۵. دیتابیسمون (postgresql) رو روی B نصب میکنیم و سرویسش رو فعال میکنیم :# Install the repository RPM: dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm # Disable the built-in PostgreSQL module: dnf -qy module disable postgresql # Install PostgreSQL: dnf install -y postgresql13-server # Optionally initialize the database and enable automatic start: /usr/pgsql-13/bin/postgresql-13-setup initdb systemctl enable postgresql-13 systemctl start postgresql-13۶. سرویس gitea رو از طریق دستور زیر ایجاد میکنیمvi /etc/systemd/system/gitea.serviceو خطوط پایین رو داخل فایل کپی و ذخیره میکنیم[Unit]Description=Gitea (Git with a cup of tea)After=syslog.targetAfter=network.target#### Don't forget to add the database service requirements#####Requires=mysql.service#Requires=mariadb.serviceRequires=postgresql-13.service#Requires=memcached.service#Requires=redis.service##### If using socket activation for main http/s#####After=gitea.main.socket#Requires=gitea.main.socket##### (You can also provide gitea an http fallback and/or ssh socket too)## An example of /etc/systemd/system/gitea.main.socket####### [Unit]## Description=Gitea Web Socket## PartOf=gitea.service#### [Socket]## Service=gitea.service## ListenStream=## NoDelay=true#### [Install]## WantedBy=sockets.target#####[Service]# Modify these two values and uncomment them if you have# repos with lots of files and get an HTTP error 500 because# of that####LimitMEMLOCK=infinity#LimitNOFILE=65535RestartSec=2sType=simpleUser=gitGroup=gitWorkingDirectory=/var/lib/gitea/# If using Unix socket: tells systemd to create the /run/gitea folder, which will contain the gitea.sock file# (manually creating /run/gitea doesn't work, because it would not persist across reboots)#RuntimeDirectory=giteaExecStart=/usr/local/bin/gitea web --config /etc/gitea/app.iniRestart=alwaysEnvironment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea# If you want to bind Gitea to a port below 1024, uncomment# the two values below, or use socket activation to pass Gitea its ports as above####CapabilityBoundingSet=CAP_NET_BIND_SERVICE#AmbientCapabilities=CAP_NET_BIND_SERVICE###[Install]WantedBy=multi-user.targetو در نهایت systemctl enable giteaخوب تا اینجا تنظیمات اولیه B رو انجام دادیم (مراحل مشابه با مراحل نصب بود) و با دستور زیر میتونیم gitea رو اجرا کنیم :systemctl enable giteaاما میرسیم به اصل ماجرا یعنی انتقال اطلاعات A به Bبرای اینکه کلیه اطلاعاتی که روی A داشتیم شامل یوزر ها دسترسی ها و ریپازیتوری ها رو به B منتقل کنیم باید سه کار انجام بدیم :۱.انتقال دیتابیسبرای اینکار وارد A میشیم و از دیتابیس A بک آپ میگیریم :pg_dumpall -U postgres > db.sqlخوب حالا باید فایل db.sql رو به B منتقل کنیم پس از طریق ssh وارد B میشیم و با کامند scp فایل بک آپ رو به B منتقل میکنیم :scp root@A:/path/to/backup/db.sql /optدستور بالا میگه فایل بک رو از آدرس /path/to/backup/db.sql روی سرور A (به جای A از آی پی استفاده کنید) کپی کن و توی B در مسیر /opt قرار بده. بعد از وارد کردن دستور بالا از شما پسورد یوزر root در A خواسته میشود و بعد از وارد کردن پسورد فرایند انتقال آغاز میشود.بعد از اتمام فرایند انتقال با استفاده از دستور زیر db.sql را وارد دیتابیس B میکنیم :sql -U postgres -f /opt/db.sql postgres۲.انتقال ریپازیتوری هایی که روی A ایجاد کرده بودیمبرای اینکار مجددا وارد A lمیشیم و به مسیر زیر که محل ذخیره ریپازیتوری ها بوده می رویم :cd /home/gitسپس فولدر gitea-repositories را زیپ میکنیمzip -r rep.zip gitea-repositories/دوباره وارد B میشیم و برای انتقال ریپازیتوری ها مجدد از دستور scp استفاده میکنیم :scp root@A:/home/git/rep.zip /home/gitسپس پسورد یوزر root در A را وارد میکنیم و پس از اتمام انتقال فایل rep.zip را از حالت فشرده خارج میکنیمunzip /home/git/rep.zip۳.میرسیم به مرجله پایانی یعنی کپی کردن فایل تنظیمات. دستور زیر رو توی B اجرا میکنیم تا تنظیماتمون رو از A به B منتقل کنیم scp root@A:/etc/gitea/app.ini /etc/gitea/و تامام...!systemctl enable gitea اجرای دستور بالا توی B اپلیکیشن gitea رو اجرا میکنه و از طریق پورتی که توی فایل تنظیمات (app.ini)قبلا تنظیم کرده بودیم میتونیم به وب اپیکیشن دسترسی داشته باشیم.نکته : اگه از دیتابیس دیگه ای استفاده میکنید همه مراحل مشابه هستن فقط قسمت نصب و بک اپ/ری استور دیتابیس متفاوته و البته داخل فایل سرویس هم باید خط زیر رو کامنت کنیدRequires=postgresql-13.serviceو به جاش سرویس مربوط به دیتابیس خودتون رو بذاریدفقط میمونه باز کردن پورت gitea روی B و احتمالا تنظیمات nginx که میتونید توی پست های مرتبط با نصب gitea توی همین ویرگول پیداش کنید.سعی کردم تا جایی که میشه کامل و مبتدی توضیح بدم. اگه سوالی بود توی قسمت نظرات بپرسید حتما جواب میدم ;)موفق باشید.

تست واحد چیست؟؟؟

آیدین نصراله پور — Sun, 20 Sep 2020 13:56:22 +0430

تو پست آیا برنامه نویس باید کدهاشو تست کنه؟؟؟ لزوم نوشتن و انجام تست توسط برنامه نویس رو بررسی کردیم. تو این پست و چند پست آینده انواع تست هایی که باید توسط برنامه نویس اجرا بشه رو بررسی میکنیم.تست واحد چیست ؟؟؟ایده اصلی تست واحد یا همون Unit test حصول اطمینان از کارکرد صحیح کلاسی است که در حال توسعه آن هستیم. به این صورت که اگر داده مشخصی را به عنوان ورودی در واحد تحت تست وارد کنیم، خروجی مشخص مورد انتظار را به عنوان خروجی دریافت خواهیم کرد. یا اگر ورودی نا مربوطی وارد کنیم، خطایی مطابق انتظار پاسخ میگیریم. پس با تست واحد از رفتار مورد انتظار واحد تحت تستمون مطمین میشویم.اما نکته مهم اینجاست که برای اطمینان از اینکه واحد تحت تست در هر شرایط و هر محیطی کار میکنه، کلاس ها باید به صورت ایزوله تست شوند. یعنی هنگام نوشتن unit test فقط یک کلاس را تست کنید نه بیشتر. بعد از اینکه مطمین شدید کدتان به درستی کار میکند، تعامل آن قطعه با سایر اجزای سیستم را تست کنید. ولی ابتدا روی تست واحد تمرکز کنید.برخی افراد تنها به این دلیل که تستهایشان را در فریمورک های تست واحد اجرا می کنند تمام تست هایشان را تست واحد میدانند. برخی دیگر با نوشتن تستهایی که در برگیرنده لایه های مختلف است با این فرض که این لایه ها در اصل یک واحد بزرگ را تشکیل میدهند به خیال خود unit test مینویسند.در کتاب A set of Unit Testing Rules که توسط Michael Feathers نوشته شده آمده :تست نوشته شده اگر شرایط زیر را داشته باشد تست واحد نیست : 1. با دیتابیس ارتباط برقرار کند.2. با شبکه ارتباط برقرار کند.3. با فایل سیستم سر و کار داشته باشد.4. برای اجرای آن نیاز به اعمال تنظیمات(افزودن یا تغییر فایل های کانفیگ) داشته باشید.تست های واحد مشخصه هایی داردند که آنها را از سایر تست های برنامه نویس مجزا میکنند. همانطور که گفته شد این تست ها بر روی یک کلاس متمرکز میشوند و از آنجا که معمولا کوچک هستند سریع اجرا میشوند. همچنین محل باگ ها را شناسایی کرده و به سرعت و با دقت بالا برنامه نویس را به خطی که کد خطا دار نوشته شده است هدایت می کند و به این ترتیب به برنامه نویس کمک میکند تا قبل از پخش شدن باگ در سیستم آن را رفع کند.اگر تست های واحدی که نوشته اید تمام کلاسهایتان را به طور کامل پوشش داده باشند، در هر زمان بدون ترس می توان کد ها را ریفکتور کرد وهیچ کدی که جرعت تغییر دادنش رو نداشته باشید وجود نخواهد داشت.مزیت دیگر این تست ها داشتن یک مستند گویا و به روز از کدهایمان هست. تست های واحد بسیار راحت تر و سریع تر از داکیومنت ها و کامنت های موجود در کد فهمیده میشوند.در آخر یادمون باشه که تست های واحد وظیفه و ابزار برنامه نویسان هستند که اگر به صورت درست انجام شوند مایع افتخار و نشانه حرفه ای بودن برنامه نویس میباشد.

آیا برنامه نویس باید کدهاشو تست کنه؟؟؟

آیدین نصراله پور — Sat, 19 Sep 2020 11:15:24 +0430

احتمالا خیلی شنیدید که میگن برنامه نویس نباید کد خودشو تست کنه. دلایل زیادی هم برای این ادعا وجود داره که بهترینشون عبارت اند از :برنامه نویس ها معمولا مهارت تست خوبی ندارندشما نباید قاضی خودتون باشید !!!اگر بخوایم منصف باشیم، هردوی این دلایل منطقی هستن و بدون شک در پروژه های واقعی نرم افزاری خودشون رو نشون دادند و نباید به سادگی از کنارشون گذشت. اما به نظر من این دلایل سوتفاهم در هدف تست ایجاد میکنن.اگر از تست نهایی (قبل از تحویل به مشتری) صحبت می کنیم پس حتما باید تستر های حرفه ای و با تجربه تست ها رو اجرا کنن. همه ما قبول داریم که هیچ برنامه نویسی نمی تونه در محیط های گرافیکی به دقت و کنجکاوی یک تستر عمل کنه. ولی این تنها تستی نیست که میشه انجامش داد. تست های مختلف دیگری هم هستند که باید توسط خود توسعه دهنده انجام بشه.کما اینکه خیلی وقت ها تست کردن برنامه توسط کسی به جز خود برنامه نویس کار سختیه. تست نرم افزار از دید کاربر ( بخوانید تست اند تو اند) بسیار حیاتی است ولی این تست تنها قطعه پازل نیست. قبل از انجام این تست، تیم توسعه دهنده باید نرم افزاری تولید کرده باشه که تست های برنامه نویس را پاس کنه در غیر این صورت یه نرم افزار بی کیفیت تولید و تحویل شده.همچنین پیدا کردن باگ ها در زمان توسعه باعث کاهش هزینه و زمان در اصلاح باگ میشود.هرچه باگ ها سریع تر شناسایی شوند، هزینه کمتری ایجاد میکنن.تست های برنامه نویس اولین خط دفاع در برابر باگ هستن. اگه باگی در این مرحله پیدا بشه سریع رفع میشه. البته ممکنه بنا به دلایلی بعضی باگ ها پنهان بمونن که به همین دلیل خطوط دفاعی دیگری هم وجود داره و شکار باگ های پنهان به عهده اون ها (متخصصین تست نرم افزار) است.بسیاری از کمپانی های بزرگ مثل فیسبوک و وردپرس تنها به تست های توسعه دهنده بسنده میکنن و رویکرد استقرار مداوم رو اتخاذ میکنن. یعنی هر فیچر جدیدی که تست های اتوماتیک رو پاس کنه میره روی محیط عملیاتی.- بنابراین آیا برنامه نویس باید کد های خودش رو تست کنه ؟؟؟+ بله