In Heroku, connected to Git. I want to deploy my Dev branch, and can select it.
When I manually deploy it does it's thing (deploys my website to Heroku). But my website has Master branch code. I go back to Heroku and it's on Master.
If I select Dev as the branch for either Manual or Automatic, then reload the page, it switches back to Master. Below is a screenshot of me setting the branch to dev. If I do a browser refresh, it resets to Master.
I tried reconnecting Github. Not sure what else it could be.
Deploying Dev was working up until yesterday.
Here is a screenshot of how I manually deploy (as opposed to auto deploy) from the Heroku Deployment tab.
Edit: I should also add, I happily was on Dev, and could deploy Dev updates up until recently. I deployed Master by mistake, bat can't go back to Dev.
I ended up having a corrupt Collection / DB record. I was tipped on another forum that the symptoms I was seeing (Nighscout web app not displaying some data, not the Heroku deploy I was attempting to work around that issue) could be caused by that. So as a last resort I dropped the entire Mongo Collection and I can now deploy Master and Dev, and it sticks in Heroku.
I don't know the significance since the data should be separate from the web app source code itself.
The whole reason I wanted to try Dev was for a fix for parts of the app not working. After initialising the Mongo DB Collection, I can use Master, so Dev (and the fix it contained) is not needed.
I know this isn't the exact root cause, but I'll leave this here in case someone comes across it and hasn't thought to look at the data.
Related
While doing a deployment I am seeing this error in my Heroku build log
error Bootstrap function in plugin "users-permissions" failed
Note: I was able to run the application successfully before with some default PORT number. Then I changed stuff in database.json for both production and staging envs and since then I am not able to start the application even when I revert my changes.
Any ideas?
I found out that I cannot use PORT to differentiate between staging and prod in the same APP on Heroku. And I have to create two separate apps. In the end I ended up using Pipelines and two separate apps using the same GIT repo but different branches. Seems to work fine. Now, I am just waiting for a native way to do data migrations between environments.
I have been trying to get a staging server working on Heroku where my product app runs. I thought the issue was related to a mis-configured database. There seemed to be some odd things visible in the Heroku dashboard where it showed multiple instances of Postgresql add-ons, with different names. On the production implementation of the database, it said it was also attached to my staging app - which did not seem right - so I deleted that (I want my staging app to have a clean DB and not be attached to production).
BUT... now it appears my production database is GONE. I have a support ticket in to Heroku. But would LOVE some help - I am pretty desperate at this point!
I have gone into the Activity menu for my Heroku app and rolled back to a point before the screwup - but I am pretty sure that just restores code & settings. So I am still dead as the database is not there.
To make matters worse, I quickly checked pg:backups and the list it returns is quite old. That doesn't seem right - I think I should have automatic backups - so that adds to the fear that I may have royally screwed this up.
I expected the database to detach from my staging app but remain intact for my production app. Now all that is showing is the "old" version of the database.
UPDATE: I was able to promote an instance of an older database that was still attached to my app, so the app itself is up and running (but with older data). Still waiting on Heroku support to respond to my trouble ticket and hopefully help me restore this database.
RESOLUTION: Heroku tech support responded overnight and was able to recover/restore my production database as hoped, so only minor damage done with users unable to access recent data for about 6 hours. So 2 learnings from this.
First, and fairly obvious, is to be very careful with how you manage your production DB and make sure you have regularly scheduled backups occuring (I thought I did, but after an automatic Postgres upgrade it appears those went away and I did not know to re-schedule them).
Second, that Heroku does continuously backup your app/data and can help you recover from this kind of disaster as long as you are on one of their paid plans. But you have to contact them through tech support and request this, there is no way to recover from these automatic backups via the dashboard or CLI.
I am making a small web project which I am doing on the LAMP stack using the Symfony 1.4 MVC framework. I am interested in documenting everything, right from the database to the code and I want to push all my code onto GitHub. I know how to setup a repository on GitHub and push changes etc live.
What I am unable to wrap around my head is this:
I have the development server, which after testing it out I push it onto my GitHub repository, after this I want to naturally have to push it onto my production server. Typically, this being a one man project, I can easily push the project live to my production server using rsync. And this is how I would typically configure it in my YAML files and then symfony will automatically push the changes to my production server.
Naturally, I want GitHub as the intermediary where the code to my project is saved and from there I should be able to deploy it to my production server.
But how exactly I should achieve this, I have no clue.
Can anybody suggest the missing pieces to this puzzle?
You can use Capifony to deploy your symfony project.
I'm learning FluentMigrator. The thing that I like about FM is that it supports the idea of Forward and Back for migrations (aka Up/Down). I'm finding that it's not ideal about this; there are some holes. Still, it's good.
This leads me to wonder if there are any deployment tools (nant, msbuild or other) that support this idea of rolling forward and back. The scenario that I'm using it in is the deployment of a web app with a related database.
Ideally I'd like to set up my deployment so that, should any part of it fail, it will revert to the previous known working configuration. With FM, this is pretty easy to do (but there are rough spots), so that covers the db. How about the files that make up the web app? Do any deploy tools have support for this?
Deploying to a Windows Server. Assume that I can't make any changes to the server.
I don't know of any Microsoft-centric, automated provisioning/deployment tools like Capistrano. Here are some tools I've heard of, but never used:
MSDeploy, for deploying web application.
Microsoft Deployment Services, for managing operating system configuration
Microsoft's System Center Configuration Manager
BladeLogic
HP's Operations Center
Up until about three months ago, we did our deployment/provisioning using custom MSBuild scripts. After a server is provisioned, deploys happen automatically using Robocopy to copy files to a share on the application server, updating changed application binaries and markup files. We've never had a need to rollback any of our deployments, but since our scripts are custom, we could write the logic if we needed to.
MSBuild is a terrible deployment/provisioning language. For the past three months, we've been writing all new scripts in, and porting existing ones to, PowerShell. It is wonderful. With version 2, there is support for running commands on remote servers, like SSH. We haven't used that functionality yet, but I'm looking forward to pushing setup scripts to remote server to provision and deploy at the same time.
We have been using Git to do our deploys for the last 6 months.
Here is the whole process:
CI server build the project
CI server checks it in to a local git repository
CI server pushes the changes to the centralised git repository
User creates an empty repository on the live server
User adds the central git repository to the remotes
User pulls the latest version over https (no need to open any ports)
It is a lot to setup in the beginning but once setup it works great. Deploys take seconds as only changed files get copied.
Another great thing about this method is that git keeps history of changes so rolling back is pretty simple. You can also roll back a few revisions and it's done straight on the live server. If something goes wrong reverting is super fast.
Also you can save some time if you use a hosted git service (github) for your central repository.
This is a very brief description but I can give you more info if you want.
Of course! My favorite is Capistrano. This was originally built for Ruby but I've found that it works just as well for other languages.
https://github.com/capistrano/capistrano
I am using mercurial for website development. I "think" I'm using it correctly.
I develop on my development machine, commit fairly regularly. I will somewhat regularly push my commits to my hosted site-dev repository.
If things are set up how I want them for the live site, I push from my dev machine to the hosted site-live repository. Then I pull down from that repository onto the live server.
However, there are some changes that need to be made (changing directories from localhost to www.example.com, changing the DB connection stuff, etc.).
What I did was made these changes on my live machine, then pushed them back up to the site-live repository. I don't know why I did that, really, but at least there's a changeset sitting there with the necessary config changes.
What I don't know how to do is manage this process. I'm a little lost beyond committing, pushing and pulling with hg. I'm a single developer and haven't even done a merge yet.
Is there some way to keep that particular changeset identified, and just apply it, hopefully even BEFORE I pull from the repo down to the live server?
I think you can tell from my question that I'm in a little over my head with hg and workflow at the moment ;)
This is my understanding:
What essentially you are trying to do is have a development, staging and deployment environment. You do your development using 'development' repository, test it on a staging environment and then once satisfied, pull those changes into deployment repository.
And when you pull from staging to deployment, you need to change your environment / configuration data.
My take is you should not be changing the configuration at all.
You should have configuration files such that you have a
basic configuration file
basic.conf
Environment specific overrides
basic.dev.conf, basic.staging.conf and basic. deployment.conf
Use environment variable:
The overrides to the basic configuration data should be defined via an environment
specific variable : APP_ENV : dev or staging or deploy
This way you should be able to override the configuration based on the environment without changing the configuration information.
It is not a good idea to rely on making changes to config files each time you pull your code from development to staging to deployment.
I would keep the live server outside the version control. Meaning that I would have a small "install" script that pulls updates from the repository, removes any unnecessary development files, and applies the correct configuration files. Both development and production configuration files should be in version control.