Developing OpenShift cartridges that need large binaries - openshift

When developing an OpenShift cartridge, what is the standard way to handle large binaries that it will need? Let's say a 100 MB file. Searching around the web I saw a couple cartridges that had their required binaries in the git repository, but I thought that was generally considered to be a bad idea from a git perspective.

You can either add it to your repo as you mentioned or host the file elsewhere and wget it part of your install scripts.

Related

What is the best approach towards updating a very old MediaWiki installation?

I've got a client that's running a pretty ancient version of Mediawiki (1.17.0) on an internal corporate network. It's running on PHP5, but they're looking to upgrade to PHP7. This version has basically served its purpose well and whoever was in charge never messed with upgrading it. (I know) But it won't run under PHP 7.4 and the company is upgrading their PHP systems.
Obviously there have been a TON of revisions to MediaWiki in this time. I've got a few questions...
First, what's the earliest version of MediaWiki that is PHP7 compatible?
Second, what's the best approach to updating this system? It's got over 1000 pages and 1000 images. It's not huge, but it's obviously not small, and if there's any way to automate bringing this up to the most current version, I'm curious what my options are?
I'm trying to avoid doing incremental updates because upon investigating, it's a ton of them, and not all interim versions seem to be available.
Is it possible to install a new, fresh version and copy the database/images over?
Any advice is most appreciated!
As noted in https://www.mediawiki.org/wiki/Compatibility#Upgrade , you need to upgrade first to 1.35 and then to 1.38 (or 1.39 if you wait a little - 1.39 is an LTS release so probably worth it). See the manual on upgrading on how to do it - basically, update the files in MediaWiki core and all extensions, possibly run composer update depending on your distribution (tarballs tipically already include the files that Composer would download, git doesn't), and run the upgrade script wich will migrate the DB.

Should I install MariaDB to my git repo, or locally / individually to all development computers?

I am starting work on a website that will use MariaDB for storing information (no sensitive information), and would like to keep everything in my git repo.
Originally, I planned on installing MariaDB to the separate computers that I plan to develop on (my desktop and laptop), but decided that it may be easier to store all of MariaDB (the program and the databases) in the git repo, so that one would just need to clone the repo and run MariaDB from the repo just like they would run Node, but I have not found any information on how to do this.
My questions are (1) should I install MariaDB and its databases to my git repo, instead of installing MariaDB in /usr, and the database in /var/lib/mysql, and (2) how would one do that?
Instead of attempting to put a mariadb runtime environment inside your version control, consider using docker to describe how to configure an appropriate mariaDB installation. I use makefiles atop that to contain the commands I use to build and run the docker but you coould just as easily use a shell script. Finally, provide a dataabase load script that loads your test database from a text file within the repo.
using docker to describe runtime environments for your application and dependencies is awesome. It strikes a great balance between having an incomplete git repo, and having to put binaries and database data in your version control. You wouldn't want to track changes to the underlying maria db files, anyway, so best not to commit them. You can build the docker containers you need on every workstation you use without much trouble, your automation around creating them provides a mechanism to ensure consistency, and by loading a database with the correct test data every time you develop your app, you'll have a better development process and less schema and data related changes. It works great, I do nothing but docker driven development these days.

Off-PaaS development environment for OpenShift

I would like to deploy an application to OpenShift. The application itself does not require much resources, so it could live perfectly happily in a small gear.
However, it links to some libraries that are not available on OpenShift, and I need to compile them from source. They are written in C++, and compiling C++ requires a lot of memory it seems, and the compilation fails.
What is the suggested solution to this? Can I just compile it offline, on an identical system? What is an identical system? Or should I compile it in a bigger gear, and then copy it over to the small gear?
Yes, you should be able to compile your c++ application on another binary compatible system (centos, or another RHEL install) and then just upload the binaries to your gear, keeping in mind that you need to make sure that all of the dependencies are there etc.

What's the best way (performance-wise) to publish mercurial repositories on a windows server?

I have the impression that hg server is rather slow on our Windows Server... Are there better ways to publish mercurial repositories?
A list that compares the possibilities for publishing repositories can be found here.
I'd recommend hgweb, which is probably the most flexible solution also on Windows. You can use it with Apache or IIS.

How to setup a box and 3 machines as a web development environment for a small team

Extended title: How to setup a box with (Windows7 + Apache + VisualSVN + MySQL + PHP) and 3 machines with (MacOs/Windows7) and Dreamweaver CS5 as a web development environment for a small team
These are my thoughts. Please forgive my ignorance, I still don´t have completly clear all the concepts.
1. I need to setup a web development environment for a small team of 3 web developers. The staging and live environments will be in a remote server under an external hosting company (probably Amazon).
2. Our first project is a blog with Wordpress
3. I've installed XAMPP in the box and can be accessed like this (http://dev.company.com/xampp)
4. I've installed Wordpress and can be accessed like this (http://dev.company.com/blog)
5. I've installed VisualSVN in the box and can be accessed like this (http://dev.company.com:8080/svn)
6. I don´t know how to import files for the first time to my repositories in the box (c:/repositories/blog)
7. VisualSVN includes Apache. I don´t know if I should turn off the Apache of XAMPP or if should install another version of VisualSVN without Apache
8. I don't know if I should keep my repositories at C:\repositories or c:\xampp\htdocs.
9. I've read something about hooks? to copy the files from the repositories to the htdocs? Can anybody explain this process?
10. Would it be a good option to keep all the files always in the box? or it is a better option to check out the files to the machines?
11. When setting up Dreamweaver to connect to the SVN Server, do I have to point to the trunk, branch or the name of the repository? Do I have to setup a different connection for each branch?
12. How can we include images and PSD's in the repositories?
When we start a new project we usually just checkout files on clients and commit the changes to the server when finished editing. This way people can just edit files on their own machine (without other users slowing stuff down).
Can't you just do a Linux install for the webserver (CentOS or something like that?). Windows 7 seems so heavy / unfitted for webdevelopment server.
We usually keep the repo out of the webroot.
XAMPP really???
Just my two cents...
It's strongly not recommended to use Apache HTTP server bundled to VisualSVN Server for anything else than Subversion server. So you have to install VisualSVN Server and XAMPP.
Just keep repositories in C:\Repositories. If you move them to htdocs all repository will be accessed for everyone who have access to XAMPP.
Common practice is to checkout working copy to htdocs folder, configure permissions to deny access to .svn and then run svn update in post-commit hook in VisualSVN Server.