I'm considering migration for custom hosted Rails app to Elastic Beanstalk.
I've create a simple Rails app and manage to deploy it to on Elastic beanstalk. There are still a few thing I still didn't manage to get:
How can I deploy a branch or a specific code to my app?
Is the deployed version is from last commit or my current workspace?
What are the best practices when handling deployment on Beanstalk?
Amazon have this document (link) but it seems to be deprecated and I can't figure how to do it on current version
elad:...$ eb --version
EB CLI 3.7 (Python 2.7.1)
I'm not sure my solution is the best practices or not, I just show here, welcome all comments on this.
How can I deploy a branch or a specific code to my app?
Beanstalk support deploy the last commit in current branch (which was actually uploaded to S3 firstly) by using EB command line
Deploy from a zipped file which was also actually updated to S3 after that
Here is what in in your environment settings in Beanstalk console
Is the deployed version is from last commit or my current workspace?
From last commit
3.What are the best practices when handling deployment on Beanstalk?
My solution #1: Define which branch will be deployed to a specific environment
In .elasticbeanstalk/config.yml
# .....
branch-defaults:
develop:
environment: mercury-dev-staging
master:
environment: mercury-dev
# .....
Relying on this config, I always switch to develop branch to deploy to mercury-dev-staging env, and master one for mercury-dev. This will avoid some mistakes like deploying develop branch to production env
My solution #2: Define some alias commands for quick deployment:
In ~/.bash_profile (I'm using MacOS)
alias deploy_production="eb deploy mercury-dev;"
alias deploy_staging="eb deploy mercury-dev-staging;"
Now I just type deploy_staging for staging deployment, this is convenient but risky, because you may deploy your developing feature to production.
Someone considering their options could take a look at AWS Code Pipeline. You define the specific GitHub repo branch. If you push a change to that branch, Code Pipeline detects it and starts a pipeline process.
This is relevant to Elastic Beanstalk because on Step 4 of Code Pipeline, you can deploy to AWS Elastic Beanstalk (among others).
Related
I've created a web app (ASP.NET Core API project, if it matters) and deployed it to Heroku as a docker container (using heroku.yml). That worked fine (with some obstacles that I solved).
Then I created the Heroku pipeline to have app in different environments (dev, stage, prod). I connected Heroku pipeline with the GitHub repo where my project is stored. So that gave me the staging environment of my app which works fine and opens in browser.
However, when I try to Promote to production from the staging environment I get the error:
Pipeline promotions are not supported on apps pushed via Heroku Container Registry
I am newbie to Heroku and also not expert on Docker. But why do I get this error? Why is not possible to use promotion from staging to production in a Heroku pipeline when app is deployed via docker?
Are there other options to create environments on Heroku when deploying apps via docker containers?
I'm setting production environment for a project and i need to create two environments, one for staging(testing) and one for production.
How can I do this using gitlab's CI and digitalocean's server.
DigitalOcean's server will the environment target or that's will be gitlab-runner hosts?
First you need to install at least one gitlab-runner (or use shared runners).
Use "only" to define the build (and deploy source branch) and use tags in assign build job to specified gitlab-runners
I have a jenkins job which will build and deploy grails to AWS Beanstalk, and a script which then checks the HTTP status of the deployed page. Is there a way to rollback the change if it does not return a 200?
Grab what version is running before deployment and save it.
Deploy.
If it's not a 200OK just run a beanstalk deploy on the previous version you captured.
As far as "rollbacks" no, that's usually done in single transactions to make sure data consistency is held.
I am trying to setup continuous deployment for my Rails project. So far I have done following steps:
My app is on Github.
I have setup Travis CI.
I have created staging environment. (www.staging.myappname.com)
I have created prod environment. (www.myappname.com)
I have integrated Travis CI and Github.
What I am trying to achieve.
Someone creates a pull request.
Travis CI runs the build against pull request. (this part is done)
Once Pull request is merged into master branch then Travis CI run the test again. (this part is done)
If test is green then deploy master branch to staging environment. ( I can do this by adding deploy section to .travis.yml file.
Run test against staging environment, if test passes then deploy master branch to Production environment. ( I don't know how to achieve this part )
I am not sure if this is a right way to do it or not. I read couple of blog post and I noticed people creating different git branch for staging and production. Is this approach needed?
Also I can easily push my code to staging environment using Travis CI but I don't know how to run test again on staging environment and push code to production. What type of test shall I run against staging environment? Shall I only focus on selenium test for staging environment?
I can used tool like codeship but they offer only 100 build/month for free plan where as in Travis I can get unlimited build for free plan. This is the main reason for choosing Travis over codeship.
So my question:
Am I on right track?
What type of test shall I run against staging server?
how to deploy from staging to production using Travis CI?
Do I need staging.rb file in my rails app? If yes then how will it differ from production.rb file?
Do I need to create different git branch for staging and production? Currently I have only master branch which I am trying to deploy to both staging and production.
Usually people have 2 branches, one for staging/development which deploys on the staging server and one for production which deploys to the production branch
once your staging branch is tested and ready for deployment on production, you could create a pull request from staging to master (or just merge it locally and push it) and then the CI server should detect a new version on the master branch and then deploys it to the production server.
I have a Heroku application that already deploy on Heroku (master-branch) in that I created new branch staging. The staging branch code are totally different with master. Now I want to deploy staging on Heroku but that will not affect on master. How can I do that?
You have to created separate applications on Heroku for each environment that you need. I typically create dev and staging using the free tier.
Here is blog post that walks you through the process:
http://agilewarrior.wordpress.com/2014/05/16/how-to-create-a-staging-environment-heroku/
You can run heroku buildpacks:clear -a yourAppName and redeploy the app.