Recently we've been sent an email saying "Ads scripts in your account which will need to be migrated".
Why do clients need to migrate script by script?
AFAIU, this is a web IDE migration. Meaning the scripts' code doesn't have to change. Right?
Related
I am looking into how to set up a liferay project with version control and automated deployment. I have a working local development environment in eclipse, but as far as I understand it, setting up a portal in liferay is in part the liferay portal instance running on tomcat and then my custom module projects for customization. I basically want all of that in one git repository which can then be
1: cloned by any developer to set up their local dev environment
2: built and deployed by eg. jenkins into eg. AWS
I have looked at the liferay documentation regarding creating a docker container for the portal, but I don't fully understand how things like portal content would be handled.
I would be very grateful if someone could lead me in the right direction on how a environment like this would be set up.
Code and content are different beasts. Set up a local Liferay instance for every single developer. Share/version the code through whatever version control (you mention git).
This way, every developer can work on their own project, set breakpoints, and create content that doesn't interfere with other developers.
Set up a separate integration test environment, that gets its code exclusively through your CI server, never gets touched manually.
Your production (or preproduction) database will likely have completely different content: Where a developer is quick to create a few "Lorem Ipsum" posts and pages, you don't want them to escape into production. Thus there's no movement of content from development to production. Only code moves that way.
In case you want your developers to work on a production-like environment, you can restore the production content (database) to development machines. Note that this is risky though: The database also contains user accounts, and you might trigger update notification mails from your development machines - something that you want to avoid at all costs. Plus, this way you give developers access to login data (even though it's hashed) which can be abused. And it might even be explicitly forbidden by industry regulations to use production data in development environments.
In general: Every system has its own database (at least their own schema), document store and indexing server. Every developer has their own portal JVM running. The other environments (integration test, load test, authoring, production) are also separate environments. And no, you don't need all of them all the time.
I can't attribute this quote (Milen can - see his comment), but it holds here:
Everybody has a testing environment. Some are lucky to run a completely different production environment.
Be the lucky one. If everyone has their own fully separated environment, nobody is stepping on each other's shoes. And you'll need the integration tests (with the CI output) anyway.
I use Microsoft Team Foundation Server (TFS) for most of my software deployments. TFS allows me to dynamically replace text within specific configuration files during the release process to specific environments (dev, test, prod).
The text it replaces are placeholders called "tokens". For instance, during my automated deployments, TFS will allow us to replace tokens found within configuration files with pre-defined values saved in the build administration for each environment. This way, I don't store any real credentials in source control for any environment. I also don't store any script in source that would hold these sensative credentials. The credentials are dynamically inserted over top the tokens during the release, and the credentials are hosted/saved/configured inside of the release system (not in a script).
For example, I have a configuration file (web.config) that has tokens. A token looks something like this:
MySettingName=${MYSETTINGVALUE}
During the release to DEV, I want the text ${MYSETTINGVALUE} replaced with the word TEN. During the release to PROD, I want that same ${MYSETTINGVALUE} text replaced with the word ORANGE. And I want to store those two values (TEN and ORANGE) in the release administration system, and not in a script.
How do I configure Jenkins to do this same thing?
I have searched up-and-down for this specific answer. While many blogs, articles, documentation exist, none of them speak directly to this issue.
I would prefer NOT to use some additional 3rd party software to do
this.
I would prefer NOT to kick off some manual build and supply these
values each and every time.
I would also prefer NOT to use an Operating System level system
variable (aka evironment variable). In case that server dies, I
would rather not have to remember to setup those OS environment
varialbles on the next server.
Jenkins has a built-in credentials plugin for handling secrets in builds.
See this article on how to use them: https://support.cloudbees.com/hc/en-us/articles/203802500-Injecting-Secrets-into-Jenkins-Build-Jobs
Basically it stores credentials securely and injects them into your jobs as variables which can then be used like any other.
On my Jenkins build server, I want to set an Authentication Token so that only users that know the token can fire off builds. (As described here.)
This doc page says that it should be configurable under my job's "Build Triggers" configuration.
However, my server has no such fields, and I'm running the latest version (1.546). Mine looks like this:
.
As you can see, this doesn't really look like the docs say it should.
How can I set this token?
You're missing the Trigger builds remotely (e.g., from scripts) Build Trigger:
This is only visible with Security enabled. To get this option from a freshly downloaded 1.546 WAR, I changed Configure Global Security from Anyone can do anything to at least Logged-in users can do anything. For ease/speed of testing, under Security Realm I selected Jenkins’ own user database and Allow users to sign up:
You can go to http://Jenkins-IP/jobs/me/configure to check and change your API access token. Also check whether the user you intend to use has necessary permissions to execute the builds in Manage Jenkins>Configure Global Security
Each jenkins user gets an authentication token - applicable since version 1.426 (more).
You can see yours, provided you are logged in your jenkins server, at http://your.jenkins.server/me/configure
(press 'show API token' button)
Then you can copy and paste it in your scripts (e.g. see here for an example usage).
I am currently using TFS to source changes to a web site code base. Currently, when I'm done making a change, I need to deploy the changes to a web server for review by the end user.
Generally the way I would do this is just connect to that machine via RDP, open visual studio and get latest to pull changes...
However, this only works if I'm the only one working on the entire site. If someone else RDP in to make changes, the site is locked to my TFS account, and they can't make any changes to it...
They could pull their own copy of the site into their own machine via TFS and check in the changes there but because so much of their part is done on the database (vs code) they'd have to duplicate everything they do into the website every time them commit a change, so they prefer to work directly on the machine...
is there any way to make this work, a better way to set this up so I can pull their changes into my local copy via TFS?
my biggest problem to overcome is the fact that when I Get Latest on the webserver via RDP it locks the entire solution to my TFS account, so that when they login to RDP with their credentials, they can't make any changes because the files are checked in, and of course they can't checkout because of course the solution is tied to my account.
If I can get past that I think we'd be okay.
any info is appreciated, please let me know if I can provide more context, thanks
Can you set up a different TFS workspace for each user on your RDP machine? This should allow multiple users to use the TFS client to pull the same solution on the same machine without issue.
What are the security concerns of the following scenario? (this is one of those crazy ideas that someone will try, and maybe a it's a good idea, and maybe it's a terrible idea...)
You have Rails app at example.com, and an action at https://example.com/admin/update_app
This action has the following requirements:
It requires https (and redirects if not on https)
It requires admin access
The action displays a page with a form that says "Repository password: [ ]"
This field is filtered out of the server logs, the same way that authentication to the site is filtered out, via the log filtering mechanism in Rails (i.e. this method)
This action does the following
You put your code repository password in the field and hit "Submit"
The action starts a shell script which pulls the latest updates from the stable branch of your code repository, and applies them to the site (unless repository authentication fails, in which case it stops all further steps)
The web server is restarted
An email is sent to the admin saying something simple like, "App update complete"
Don't send the password. The app could be compromised and trojaned or the filtering could fail. Instead, grant the web app read-only access to the repository via a separate account or public access.
Don't restart the server if there are no changes. Then the action is secure even without access control: unless the developer has authorized the update by updating the stable branch, nothing happens. If the stable branch is not so stable, create a separate production branch for this.
Stop the webserver before doing the update. The app might not be secure or safe to use as a mix of files from different versions.
Make sure the web server doesn't serve any metadata files left by the VCS.
Well, this all remind me re-invented capistrano deploy on server through git repository.
Only problem that:
1) what if it will be conflicts during merge(point 2)?
2) what if webserver will not restart correctly(point 3)?
3) What if branch in your repository is not so stable(point 2)?