I have a couple of questions about devops/docker/github actions.
I'm pretty new to all of this, seen some full implemented projects but I'm missing some "parts".
I'm trying to set up a "complete project" myself, just for exercise/training and getting familiar with everything.
For now, I have 3 branches: dev, uat and master.
I work on dev (it's the default branch). I create a local branch of the dev branch and push my local changes to that branch.
Every time I finish a job (let's say user login functionality), I push this to uat.
Some customers get access to the uat server and are able to test these new functionalities. After they accepted the changes, everything from uat goes to master (which is the live server).
So far so good I guess, and if I miss something or there are things I can do better please let me know!
What my questions are:
If I push changes to the dev branch, it should automatically test these changes before I'm able to open a pr to the dev branch, is this possible with Github Actions? Or do I interpret the things I read on the internet wrong?
When things are tested during this push, do I have to spin up a Docker container? Or do I test these things on the ubuntu VM given by Github Actions? What is the best practice?
I know there is the possibility to do both, but what is considered best practice?
Does someone has an example? Or a tutorial/blog about this? I'm trying to connect the dots but I'm a little stuck...
Cheers and many thanks for the help!
1 - This video explains it simple and quick
2 - If you deploy it using docker, test it using docker
3 - see 1
Edit:
This other video is also a really nice tutorial that uses docker.
Related
As devOps engineer I am doing lot of modifications in jenkins jobs/scripts/other configurations.
I am trying to find a strategy to check my modifications.
The status now is that problems comes when users use the jobs.
I cant run All the jobs every time, and part of them affect production.
Any idea?
Thanks
When i am building the web application using jenkins, during the time it is building the production site will be down. Instead of no message at all is it possible to show a custom message such as "Will be back in less than 5 minutes". I appreciate any guide. Thanks!
I would be better to use a blue-green deployment approach with Jenkins instead of having your grails site down during the build.
That way, you have two identical environments configured exactly the same way. While one environment is active and serving end users, the other environment remains idle.
You deploy to the blue environment and test there.
Then you switch, deploy on the green one and go live. The downtime is then minimal.
See grails-samples/grails-website as an example.
We use visual svn for version control. I have few cloud web servers where my websites are running.
I would like to create some repositories for the websites content. I checkout them in local editors (notepad ++), edit them and checkin to SVN. But when check-in to visualSVN, I would like them to get deployed to the webservers docroot. In some cases I would like to restart the webserver too.
Is it possible using Jenkins+deployment plugins. I am very new to jenkins, can somebody help me with some information how we can achieve this.
It is one of the scenarios Jenkins is designed for (Continuous Delivery, aka. CD). Your perfect plan might look like this:
Get a new instance of Jenkins up/running (for experiments) (if you're familiar with Docker it is one of the best ways to experiment with Jenkins);
Configure Subversion Plugin in Jenkins (integration with SVN);
Setup your first FreeStyle job in Jenkins that polls your Visual SVN server for changes (things you check-in to SVN) and learn how that works (* * * * * <~-
this polls changes from your source control an every minute, great for experiments);
Setup your second FreeStyle job that connects to one of your webservers (probably via SSH) and creates a file (simple "touch hello_world.log" is great to start with) in a special folder dedicated for that kind of tests (DO NOT MESS WITH YOUR PRODUCTUION CONTENT FOLDER(s));
Setup your third FreeStyle job that combines your experiences acquired in #1 and #2, and still writes to a test folder;
Compare results of the job output with your production deployment expectations (eq. files in place, content is processed the right way, configuration files are looking good and etc.);
Try it out on one of the production web servers, one folder/site at a time;
Apply your newly crafted delivery pipeline to the rest of servers/sites;
Learn how backup your Jenkins instance and actually make your first backup;
Try to restore your Jenkins instance from the backup made in the previous step;
Decide whether it is okay for you to maintain your own Jenkins instance or you will be better off with a hosted version of it (CloudBees Inc.);
Learn more about Pipeline in Jenkins and possibly (because it is not immediately obvious) migrate your FreeStyle job(s) to Pipeline DSL
and/or Jenkinsfile;
At times you might need to get back to "Get Started with Jenkins" manual and look up for the ideas or answers, it is okay - do not give up and feel free to post your questions here, at SO.
Hope these ideas will help you to get started.
I have a little-to-none understanding of what travis-ci is. All I know ( and I could be wrong ) is that, it is where a github code is hosted. This code has a test written in Unit Tests, and Travis is a way to automatically test whenever a new commit is pushed to github. As I said, I could be totally wrong. Wikipedia article didn't help me understand this.
But, in the case that it is a test automation software, then how do I set up a simple application? I have a github account, and I know the first step is to register in travis, connect a github account and place a travis.yml file but what is next?
Any help would be appreciated.
What Travis CI does is connects to your GitHub repository to run you code's tests (Scripts that write to confirm that your code is working) on every commit you make on GitHub. It also runs on pull requests, which makes it great for checking if a pull request breaks anything. You can get started by going to the Travis CI and hitting sign in on the top right corner. You'll sign in with your GitHub account, and on the profile page you can turn on the repositories that you want Travis CI to test. Next, you'll need to create a .travis.yml in the repositories you want to test. You didn't specify what language you to would like to use so I'll refer you to the Travis CI getting started page which has examples in every language that Travis CI supports.
If you want to read up more I reccomend taking a look at the Travis CI docs.
I am trying to migrate the setup here at the office from SVN to Git and am setting up Redmine as the host for our projects and issue management (Currently we use a version of Gforge + SVN). I should preface by saying that I'm an embedded C software developer by day and have basically zero experience with Rails or web apps, but I like trying new things so I volunteered to set up the project management tools which will take us into the future.
I have Redmine setup and am using Gitolite as the Git repo manager. Additionally, I am using the ericpaulbishop/redmine_git_hosting plugin to facilitate automatic public ssh key pushing to Gitolite and automatic repo creation when we register a new project. Everything seems to work except the repo view within the project does not keep track of the changesets. (The "History" is just empty, although when you view the files, it does show the latest version correctly)
I copied the post-receive hook from the plugin's contrib directory to the .gitolite/ common hooks, but again I know little about Ruby and how these gitolite hooks work so I don't know how to debug this. I notice there are log messages and things in the hook, but I have no idea where those are printed, etc...
I even tried the Howto on the Redmine wiki, HowTo setup automatic refresh of repositories in Redmine on commit:
#!/bin/sh
curl "http://<redmine url>/sys/fetch_changesets?key=<your service key>"
Any ideas on where I start debugging? I've been able to resolve every problem up to this point, but I'm a little stuck now. The plugin doesn't make it obvious how this is supposed to work, and to be honest, I'm not even sure if this is a problem with Redmine not reading the repo correctly (or at all), or gitolite not communicating as Redmine expects, etc...
I guess I could answer this...
I checked the issues under the Github page and I found this on:
https://github.com/ericpaulbishop/redmine_git_hosting/issues/89
Which was pretty much exactly my problem. This does appear to be a small bug in the plugin, but you can work around it by changing Max Cache Time to "1 minute or until next commit". This immediately fixed my problem. I simply left it like that but one of the posters claimed that you could change it back to until next commit and it works from then on...