We use Gitlab CE. We have two repos / projects, one to store the source code, and the other one to build and store the package that we’ll deploy. We use a runner to push the changes in the former into the latter. This used to trigger the pipeline of the latter repo. Recently, a change was pushed to the latter repo manually, and since then the push from the runner doesn’t trigger the pipeline any more in the target repo (manual pushes still trigger the pipeline, also, the push in the runner runs flawlessly, and the commit appears in the target repo). I was not the one who created the setup, so I don’t know how to make the push from the runner trigger the pripeline (or, rather, why it doesn’t do it automatically).
As far as I understand, the push should trigger the pipeline wherever it comes from. So why doesn't it do so?
So apparently the issue appeared because the user account to which the deploy key used in the target repo belonged to has been disabled. Creating a new key with an active user account solved the problem, the pipeline is triggered properly now.
Related
I have vue project which published on Digital Ocean. The main problem is when i make some changes on FileZilla it is not affect on website. How can i solve this issue?
This is not an issue per-se. This is just the way how modern web development works. Vue.js (but also Nuxt) is using a bundler right now (Webpack, Vite are the most common), hence to go to production it needs to be bundled each time you push something to it.
If you upload something via FTP or SSH and edit some source code, a bundle step will be required in order to get any changes on the actual webapp.
Backend languages may not need that, for example you could SSH into a server and change some .php file, if you F5 the page it will be updated in real time. But this is not how frontend JS code works, it needs to be optimised.
Another thing, sending code via SSH/FTP is not really a good workflow because it is not easily trackable, no version-controlled, will not trigger any build flags in case of an error etc...
The best approach is to have a git repo + some build step included in some CI.
A common platform for it is Netlify, you connect a Github repo, you tell which command to use to build the project and each time you push some code, it may do some checks/tests/optimizations/etc... via Github Actions before being released automatically to production (updated on your webapp).
This workflow have a lot of benefits as one may tell but is also de-facto, the official/regular approach for modern Web development on the frontend.
Drone events support "push", "pull_request", "tag", "deployment"
https://github.com/drone/drone-yaml-v1/blob/1c89a78f3ae4c8c70114203034a81fec59474bc2/main.go#L30
I have two questions:
When tag and deployment will be trigger?
who will trigger it?
tag events are triggered when you tag a commit (for instance, via the Releases page of your Github repo).
deployment events can be triggered via the Github Deployments API.
Both are ways for you to control when exactly a new version of your code is (build and) deployed.
For example, a common pattern is to always automatically deploy changes to your master branch to your dev environment and only deploy a tagged version to production (using the aforementioned Github releases or Deployments API).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed last year.
Improve this question
I want to design a wordpress development process like in following picture:
First I want to create a bitbucket repository for my Wordpress site. From this repository all our software developers should able to clone the site to their local machines for developing. For developing all developers should have one local database to test changes.
After a developer finished a task he should be able to push his changes to the repo. When a sprint is done I want to send all changes from the repo with Jenkins pipeline/job to the test environment. At this environment a tester should be able to test all new functions with a cloned database from the prod system (including the dev changes).
When all tests are successfully done I want be able to apply the database changes to the prod system (with a SQL script) and send all changes with an other Jekins pipeline/job to the prod system.
Do you think this can work? Whats with plugin updates? Can I setup environment variables for each system so the plugin updates can be just done on the dev machine?
I'm not sure if this could work because a plugin or plugin update creates a lot of new database changes and I think I need a tool who can display all changes like Sourcetree for git.
Is there someone who has expert knowledge with wordpress and this kind of development process and can share his experience with me?
Or do you think this process is not working with wordpress? If this is true it would be realy bad because I need a process like this.
Thanks a lot!
I don't really know Wordpress, but the process you describe is definitely possible (I've implemented similar solutions on Drupal and Adobe Experience Manager, for instance).
However...
It's hard.
In a CMS project, a change/new feature can include:
a code change (PHP, CSS, JavaScript)
a database structure change (e.g. a new table)
a database content change (e.g. a copy fix, or default/test content)
a configuration change
Working out which version should get what is really hard. You want a developer to commit a change, and have that change replicated on QA with test content - but once QA sign it off, you probably don't want to promote that test content to production. And config changes should probably flow between systems but with different values for each environment.
For managing the database changes, I've found a plug-in that monitors database changes; no idea how scriptable that is.
See WP Activity Log.
What I've done in the past in similar situations is write a script that creates the database definition for each change - so a developer can run that script, and commit it as part of their code change. It requires a lot of discipline, though - you can only modify the database structure by using the scripts.
The correct answer is yes you can do this. I know WordPress, Bit-bucket, GIT, SVN, Linux, Ubuntu exceptionally well. I have built a system very similar to what you describe and use it daily.
The problem stated is the CMS can get tricky. That is true, but you need to use the correct tools for the correct upgrades. So, WordPress ALREADY has versioning and revisions built into it. The DATABASE doesn't need to be involved at all
First off. The database doesn't need to be updated unless you are updating plugins. But for strict development no DB pushes are necessary. So have your developers check files in and out of Bit-bucket. When the lead developer approves the changes have him migrate / push to the MASTER BRANCH in your REPO. Inside of bit-bucket there is a tool called GIT HOOKS. You can trigger a php file on the server every time there is a push to the production branch. What the PHP file does is simply trigger the linux command GIT PULL which will update all the code on the server with what in on your PRODUCTION BRANCH. GIT PULL will also remove any files if files were removed etc. On the server you will have a "checked out" copy of the GIT repo and on linux the credentials after the first clone will be stored. Simply have your PHP file trigger a BASH script that does a GIT PULL. Done.
No matter how many developers you have there will always need to be a set of eyes that reviews the code changes and merges those into production. I.e. that is where the Lead Developer comes into play.
FYI. The only directories in your wordpress instance that needs to be in bitbucket is the THEME DIRECTORY and the PLUGINS directory. You DO NOT need to sync the entire WP install which is pretty large.
In the case that you would be building custom Plugins, again, it is just code that is stored in the plugins directory. If your custom plugins are built correctly and require the use of Databases then when they are activated they will immediately build the WP DB's that are needed. Likewise, correctly built plugin will also drop its own custom table when uninstalled.
You will need to sync the 2 below directories.
Plugins folder resides in: wp-content/plugins/
Themes Folder is wp-content/themes/SELECTED_THEME
Any additional questions just ask and I am here.
From my experience it is always better to allow each developer to have their own Branch and to setup the the Dev server a dedicated master branch for quality control. you can check out some documentation on how to set this up https://plixxer.com/docs/server-management/website-quality-control/
basically you want to have a live server and dev server. The live server should only ever pull from the REPO and and the Dev and coders can pull or Push from the repo. My team treats the dev server as a quality checking station. If the current live code is not up to our standards the entire dev is rolled back to what is live on the master branch. When code in the master succeeds our standards we pull from the master branch onto the live server. Each developer should have their own branch for testing on their local server. Let me know if you need some help on setting up a local environment with GIT.
You will want to make a distinction around "build" and another around "release". The workflow I understand is that developers call their local workstations "dev", and pull request their work to the develop branch (you may have already read through Gitflow). Then, using your choice of CI automation, you get the latest source into a build area and do that - build it. Check out Ansible. If you have BitBucket, maybe you also want to organize your sprint with the likes of Jira? Then you have pretty seemless integration of your sprint objectives with actual branches containing the relative work/source. Ansible can help you automate builds and releases to the point where you are doing daily builds, and running the unit tests across your builds in the various integration environments.
During builds, you would have different configuration files being factored in depending on the target environment. This is how to care for environment configuration. It is part of the build process, and ideally all configuration is possible through the build. For example, a connection string might be different across the environment if you are having different databases to isolate migration of schema changes. For example, in a Angular application you would execute ng b --prod to build production and this would bring in a production configuration file during build to change the connection string (for example).
More about configuration specific to environments... you can also include post deployment scripts that get deployed and executed after files are uploaded so that they will configure the environment as required.
Ask your questions below, and I will do my best to build this out into a comprehensive guide.
I am a QA automation engineer and I am investigating docker as a potential way to run our tests.
Traditionally we have followed the git flow method where essentially where you have a dev and a master branch. Dev are constantly merging their new changes to the dev branch. When we wish to release, we will have a code cut off, where everything currently on the dev branch is deemed to be part of the next release. Script is then run to create the release candidate and this is deployed to staging. Any fixes that need to be done are made to the release branch and once ready to go to prod, new code is merged to master and deployed. Master is back merged to all branches so that everything is up to date. (described in more detail here: http://nvie.com/posts/a-successful-git-branching-model/).
So my question is with docker do you need to have this workflow? Im thinking of maybe having a workflow like describe below:
Dev start working on a new feature.
Dev pulls master, creates feature branch - does his dev work - unit tests pass, dev is happy for work to go to QA
Dev runs script to create release candidate (which would involve pulling master again in case new code has been merged to master by another dev),
Docker then spins up a container with multiple containers inside that (front end app, DB instance etc)
Tests (unit, api, selenium integration etc) are then run against this release candidate and if good deploy to production.
So do I need a staging env in the traditional sense where it is constantly available?
I think you're conflating two things: a continuous integration environment and a staging environment. Docker does make it easy to bring up a fresh instance of your entire stack for continuous integration (see drone for a good example), but generally you still need a staging environment that is always available to test against before deploying to prod. This staging environment should be running the same docker images that eventually get deployed to prod.
While I only have a github repository that I'm pushing to (alone), I often forget to run tests, or forget to commit all relevant files, or rely on objects residing on my local machine. These result in build breaks, but they are only detected by Travis-CI after the erroneous commit. I know TeamCity has a pre-commit testing facility (which relies on the IDE in use), but my question is with regards to the current use of continuous integration as opposed to any one implementation. My question is
Why aren't changes tested on a clean build machine - such as those which Travis-CI uses for post-commit tesing - before those changes are committed?
Such a process would mean that there would never be build breaks, meaning that a fresh environment could pull any commit from the repository and be sure of its success; as such, I don't understand why CI isn't implemented using post-commit testing.
I preface my answer with the details that I am running on GitHub and Jenkins.
Why should a developer have to run all tests locally before committing. Especially in the Git paradigm that is not a requirement. What if, for instance, it takes 15-30 minutes to run all of the tests. Do you really want your developers or you personally sitting around waiting for the tests to run locally before your commit and push your changes?
Our process usually goes like this:
Make changes in local branch.
Run any new tests that you have created.
Commit changes to local branch.
Push local changes remotely to GitHub and create pull request.
Have build process pick up changes and run unit tests.
If tests fail, then fix them in local branch and push them locally.
Get changes code reviewed in pull request.
After approval and all checks have passed, push to master.
Rerun all unit tests.
Push artifact to repository.
Push changes to an environment (ie DEV, QA) and run any integration/functional tests that rely on a full environment.
If you have a cloud then you can push your changes to a new node and only after all environment tests pass reroute the VIP to the new node(s)
Repeat 11 until you have pushed through all pre-prod environments.
If you are practicing continuous deployment then push your changes all the way to PROD if all testing, checks, etc pass.
My point is that it is not a good use of a developers time to run tests locally impeding their progress when you can off-load that work onto a Continuous Integration server and be notified of issues that you need to fix later. Also, some tests simply can't be run until you commit them and deploy the artifact to an environment. If an environment is broken because you don't have a cloud and maybe you only have one server, then fix it locally and push the changes quickly to stabilize the environment.
You can run tests locally if you have to, but this should not be the norm.
As to the multiple developer issue, open source projects have been dealing with that for a long time now. They use forks in GitHub to allow contributors the chance to suggest new fixes and functionality, but this is not really that different from a developer on the team creating a local branch, pushing it remotely, and getting team buy-in via code review before pushing. If someone pushes changes that break your changes then you try to fix them yourself first and then ask for their help. You should be following the principle of "merging early and often" as well as merging in updates from master to your branch periodically.
The assumption that if you write code and it compiles and tests are passed locally, no builds could be broken is wrong. It is only so, if you are the only developer working on that code.
But let's say I change the interface you are using, my code will compile and pass tests
as long as I don't get your updated code That uses my interface.
Your code will compile and pass tests as long as you don't get my update in the interface.
And when we both check in our code, the build machine explodes...
So CI is a process which basically say: put your changes in as soon as possible
and test them in the CI server (it should be of course compiled and tested locally first).
If all developers follow those rules,
the build will still break, but we will know about it sooner rather than later.
The CI server is not the same as the version control system. The CI server, too, checks the code out of the repository. And therefore the code has already been committed when it gets tested on the CI server.
More extensive tests may be run periodically, rather than at time of checking in, on whatever is the current version of the code at the time of testing. Think of multi-platform tests or load tests.
Generally, of course, you'll unit test your code on your development machine before checking it in.